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>

Le fichier appengine-api.jar inclus avec la Google Cloud CLI sous platform/google_appengine/google/appengine/tools/java/lib/impl/appengine-api.jar représente l'API App Engine pour Java. Vous pouvez également accéder à ce fichier à l'aide du dépôt Maven, qui contient la liste de toutes les versions.

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></version>
</dependency>

OK

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.

Remarque : Si vous utilisez des API de création de thread Java, Cloud Trace n'affiche pas correctement l'ID de la requête. Google travaille actuellement sur une solution à ce problème.

Une application peut effectuer les opérations suivantes :

• Mettre en œuvre java.lang.Runnable
• Créer une fabrique de threads en appelant com.google.appengine.api.ThreadManager.currentRequestThreadFactory()
• Appeler la méthode newRequestThread de la fabrique en transmettant l'objet Runnable (newRequestThread(runnable)), ou utiliser l'objet Fabrique renvoyé par com.google.appengine.api.ThreadManager.currentRequestThreadFactory() avec un ExecutorService (par exemple, avec un appel Executors.newCachedThreadPool(factory))

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

Remarque : Google recommande que tous les nouveaux projets utilisent gcloud CLI, qui est compatible avec Maven, Gradle et Intellij.

Le SDK App Engine pour Java (compatible avec le plug-in Maven et le plug-in Gradle) est également entièrement compatible et recommandé pour les projets existants qui ne sont pas prêts à migrer vers gcloud CLI.

IDE compatibles

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 :

• Plug-in Apache Maven basé sur gcloud CLI
• Plug-in Gradle basé sur gcloud CLI

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.

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.

Versions Java d'App Engine

Tous les artefacts publiés commençant par la version 2.x.x utilisent le mécanisme de publication Open Source. Les artefacts publiés qui commencent par la version 1.9.9xx ou une version antérieure utilisent le système de compilation interne. Pour en savoir plus, consultez le dépôt GitHub.

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 Google 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.