Environnement d'exécution Java 8

Avec App Engine, vous pouvez créer des applications Web qui utilisent l'infrastructure et les services évolutifs de Google. App Engine exécute votre application Web à l'aide d'une JVM Java 8. App Engine appelle les classes de servlets de votre application pour gérer les requêtes et préparer les réponses dans cet environnement.

La plate-forme App Engine fournit de nombreux services d'API intégrés que votre code peut appeler. Votre application peut également configurer des tâches planifiées qui s'exécutent à des intervalles donnés.

Spécifier l'environnement d'exécution Java 8 pour votre application

Pour que votre application utilise l'environnement d'exécution Java 8, ajoutez la ligne suivante dans votre fichier appengine-web.xml :

<runtime>java8</runtime>

Notez que les applications App Engine existantes qui utilisaient précédemment l'environnement d'exécution Java 7 basculeront vers l'environnement d'exécution Java 8 avec cette simple modification.

L'API App Engine pour Java est représentée par le fichier appengine-api-*.jar inclus dans le SDK App Engine dans le SDK Cloud (où * représente la version de l'API et du SDK App Engine).

Sélectionnez la version de l'API utilisée par votre application en incluant ce fichier JAR dans le répertoire WEB-INF/lib/ de l'application, ou utilisez Maven pour gérer les dépendances. Si une nouvelle version de l'environnement d'exécution Java est mise à disposition et qu'elle comporte des modifications non compatibles avec les applications existantes, cet environnement portera un nouveau numéro de version.

Utiliser Maven pour gérer les dépendances

Vous pouvez utiliser Maven pour gérer toutes les dépendances. Par exemple, cette entrée pom.xml inclut la dernière API App Engine (Rappengine-api-1.0-sdk) disponible auprès de Maven Central :

<dependency>
    <groupId>com.google.appengine</groupId>
    <artifactId>appengine-api-1.0-sdk</artifactId>
    <version>1.9.90</version>
</dependency>

Bac à sable

L'environnement d'exécution Java d'App Engine répartit les requêtes aux applications sur plusieurs serveurs Web et évite que les applications interfèrent les unes avec les autres. La réponse d'une application App Engine ne doit pas être ralentie. Une requête Web adressée à une application doit être traitée dans le délai d'expiration de la requête. Les processus qui dépassent cette limite de temps de réponse sont interrompus afin d'éviter de surcharger le serveur Web.

Notez que le seul endroit où les utilisateurs sont autorisés à écrire des fichiers est le répertoire /tmp. Les fichiers hébergés dans /tmp consomment la mémoire allouée à votre instance. Les fichiers stockés à cet emplacement sont disponibles uniquement pour cette instance spécifique et uniquement pour sa durée de vie.

Pour que votre application obtienne les fichiers de ressources dont elle a besoin, la méthode générale consiste à empaqueter ces fichiers au sein de votre application dans le répertoire WEB-INF, puis à les charger depuis votre application au moyen des méthodes Class.getResource(), ServletContext.getResource() ou d'autres méthodes similaires. Par défaut, tous les fichiers figurant dans le fichier d'archives WAR sont des "fichiers ressources". Vous pouvez exclure des fichiers de cet ensemble à l'aide du fichier appengine-web.xml.

Ordre des fichiers JAR pour le chargement des classes

Parfois, il peut être nécessaire de redéfinir l'ordre dans lequel les fichiers JAR sont analysés pour identifier les classes afin de résoudre les conflits entre noms de classes. Vous avez donc la possibilité d'accorder la priorité à certains fichiers JAR en ajoutant une section <class-loader-config> contenant des éléments <priority-specifier> dans le fichier appengine-web.xml. Exemple :

<class-loader-config>
  <priority-specifier filename="mailapi.jar"/>
</class-loader-config>

Dans cet exemple, mailapi.jar est le premier fichier JAR dans lequel il faut rechercher des classes, excluant ainsi les fichiers du répertoire war/WEB-INF/classes/.

Si plusieurs fichiers JAR sont hiérarchisés, leur ordre de chargement initial (l'un par rapport à l'autre) sera utilisé. En d'autres termes, l'ordre des éléments <priority-specifier> n'est pas pris en considération.

Threads

Dans l'environnement d'exécution Java 8, vous pouvez créer des threads à l'aide de l'API ThreadManager d'App Engine et des API intégrées de Java, par exemple new Thread(). À l'heure actuelle, si vous souhaitez appeler les API App Engine (com.google.appengine.api.*), vous devez le faire depuis un thread de requête ou un thread créé à l'aide de l'API ThreadManager.

Une application peut effectuer les opérations suivantes :

Si vous créez un ThreadPoolExecutor avec currentRequestThreadFactory(), shutdown() doit être explicitement appelé avant la fin de la requête de servlet. Si ce n'est pas le cas, la requête ne se termine pas et le serveur d'application finit par échouer. Notez que certaines bibliothèques peuvent créer des ThreadPoolExecutors pour vous.

Une application peut appliquer des opérations au thread en cours, par exemple thread.interrupt().

Chaque requête est limitée à 50 threads de requêtes d'API App Engine simultanés.

Lorsque vous utilisez des threads, utilisez des objets d'accès simultané de haut niveau, tels que Executor et Runnable. Ceux-ci s'occupent de nombreux détails de concurrence subtils, mais importants, tels que les interruptions ainsi que la planification et la tenue des registres.

Le nombre maximal de threads d'arrière-plan simultanés créés par l'API App Engine est de 10 par instance. (Cette limite ne s'applique pas aux threads Java normaux non liés à l'API App Engine.)

Outils

IDE compatibles

Cloud Tools for Eclipse ajoute de nouveaux assistants de projet et de nouvelles configurations de débogage à votre IDE Eclipse pour les projets App Engine. Vous pouvez déployer vos projets App Engine en production directement depuis Eclipse.

Cloud Tools for IntelliJ vous permet d'exécuter et de déboguer des applications App Engine dans IntelliJ IDEA. Vous pouvez déployer vos projets App Engine en production sans quitter l'IDE.

Outils de compilation compatibles

Pour accélérer votre processus de développement, vous pouvez utiliser les plug-ins App Engine pour Apache Maven ou Gradle :

Serveur de développement local

Le serveur de développement exécute votre application sur votre ordinateur local à des fins de développement et de test. Le serveur simule les services Datastore. Le serveur de développement peut également générer une configuration pour les index Datastore sur la base des requêtes exécutées par l'application durant les tests.

AppCfg

AppCfg est inclus dans la version autonome du SDK App Engine pour Java. Il s'agit d'un outil polyvalent qui gère les interactions en ligne de commande avec votre application s'exécutant sur App Engine. AppCfg peut transférer l'application vers App Engine ou simplement mettre à jour la configuration des index Datastore afin que vous puissiez créer des index avant de modifier le code. Il peut également télécharger les données de journalisation de l'application de sorte que vous puissiez analyser ses performances à l'aide de vos propres outils.

Concurrence et latence

La latence de votre application a le plus grand impact sur le nombre d'instances nécessaires pour desservir votre trafic. Si vous traitez les requêtes rapidement, une seule instance peut gérer un grand nombre de requêtes.

Les instances à un seul thread peuvent gérer une requête simultanée. Par conséquent, il existe une relation directe entre le temps de latence et le nombre de requêtes pouvant être traitées sur l'instance par seconde. Par exemple, une latence de 10 ms équivaut à 100 requêtes/seconde/instance.

Les instances à plusieurs threads peuvent gérer de nombreuses requêtes simultanées. Par conséquent, il existe une relation directe entre le temps de processeur consommé et le nombre de requêtes par seconde.

Les applications Java sont compatibles avec les requêtes simultanées. Ainsi, une même instance peut gérer de nouvelles requêtes en attendant que les autres requêtes soient terminées. La simultanéité réduit considérablement le nombre d'instances requises par votre application, mais vous devez concevoir votre application pour le fonctionnement multithread.

Par exemple, si une instance B4 (environ 2,4 GHz) consomme 10 Mcycles/requête, vous pouvez traiter 240 requêtes/seconde/instance. Si elle consomme 100 Mcycles/requête, vous pouvez traiter 24 requêtes/seconde/instance. Ces chiffres sont le cas idéal mais sont assez réalistes par rapport à ce que vous pouvez accomplir sur une instance.

Variables d'environnement

Les variables d'environnement suivantes sont définies par l'environnement d'exécution :

Variable d'environnement Description
GAE_APPLICATION ID de votre application App Engine. Cet ID est précédé du préfixe "region code~", tel que "e~" pour les applications déployées en Europe.
GAE_DEPLOYMENT_ID ID du déploiement actuel.
GAE_ENV Environnement App Engine. Variable définie sur standard.
GAE_INSTANCE ID de l'instance sur laquelle votre service est en cours d'exécution.
GAE_RUNTIME Environnement d'exécution spécifié dans le fichier app.yaml.
GAE_SERVICE Nom de service spécifié dans le fichier app.yaml. Si aucun nom de service n'est spécifié, il est défini par défaut sur default.
GAE_VERSION Libellé de la version actuelle du service.
GOOGLE_CLOUD_PROJECT ID du projet Cloud associé à votre application.
PORT Port qui reçoit les requêtes HTTP.

Vous pouvez définir des variables d'environnement supplémentaires dans le fichier app.yaml, mais les valeurs ci-dessus ne peuvent pas être remplacées.