Si vous avez apprécié cette traduction,
merci de me soutenir:
Accueil Docs Forum

L'Environment de Servlet Java

App Engine exécute votre application web Java en utilisant une JVM Java 6 dans un environnement indépendant et sécurisé. App Engine appelle les classes des Servlets de votre application pour traiter les requêtes et préparer les réponses dans cet environnement.

Sélectionner la version d'API Java

App Engine utilise l'environnement d'éxecution Java quand vous utilisez l'outil AppCfg du SDK Java pour déployer l'application.

Lors de l'écriture de ce texte, il n'y a qu'une seule version de l'API Java App Engine. Cette API est indiquée par appengine-api-*.jar inclus avec le SDK (où * représente la version de l'API et du SDK). Vous sélectionnez la version de l'API que votre application utilise en incluant ce JAR dans le répertoire de l'application WEB-INF/lib/. Si une nouvelle version de l'environnement d'éxecution Java sort et qu'elle contient des changements qui ne sont pas compatibles avec les applications existantes, cet environment aura un nouveau numéro de version. Votre application continuera d'utiliser la version précédente jusqu'à ce que vous remplaciez le JAR avec la nouvelle version (d'un nouveau SDK) et re-déployer l'application.

Requêtes and Servlets

Quand App Engine reçoit une requête web pour votre application, il invoque la servlet qui correspond à l'URL, comme décrit dans le descripteur de déploiement de l'application (le fichier web.xml dans le répertoire WEB-INF/). Il utilise l'API Servlet Java pour fournir les données entrantes à la servlet, et reçoit les données de la réponse en retour.

App Engine utilise de nombreux serveurs web pour exécuter votre application, et ajuste automatiquement le nombre de serveurs utilisés pour traiter les requêtes de façon sûr. Une requête donnée peut être routée vers n'importe quel serveur, et il se peut que ce ne soit pas le même serveur que celui qui a traité une requête précèdente du même utilisateur.

L'exemple suivant d'une classe servlet affiche un simple message sur le navigateur de l'utilisateur.

import java.io.IOException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class MyServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws IOException {
        resp.setContentType("text/plain");
        resp.getWriter().println("Hello, world");
    }
}

Réponses

App Engine appelle la servlet avec un objet requête et un object réponse, puis attend que la servlet remplisse l'objet réponse et se termine. Quand le traitement de la servlet se termine, l'objet réponse est envoyé à l'utilisateur.

App Engine ne permet pas d'envoyer des données au client, réalisant des traitements dans l'application, puis envoyant plus de données. En d'autres termes, App Engine ne permet pas le "streaming" des données en réponse à une simple requête.

Si le client envoit des entêtes HTTP avec la requête indiquant que le client peut accepter du contenu compressé (gzip), App Engine compresse les données de la réponse automatiquement et joint les entêtes de réponses appropriés. Il utilise à la fois l'entête de requête Accept-Encoding et User-Agent pour déterminer si le client peut recevoir de façon sûr des réponses compressées. Les clients spécifiques peuvent forcer la compression du contenu en spécifiant à la fois les entêtes Accept-Encoding et User-Agent avec la valeur "gzip".

Le Minuteur de Requête

Le traitement d'une requête a une durée limité pour générer et retourner une réponse, d'environ 30 secondes. Une fois le délai écoulé, le traitement de la requête est interrompu.

L'environnement d'exécution Java interrompt la servlet en lancant l'exception com.google.apphosting.api.DeadlineExceededException. Si le gestionnaire de requête n'attrape pas cette exception, l'environnement d'exécution retournera une erreur serveur HTTP 500 au client, comme pour toutes les exceptions non attrapées.

Le gestionnaire de requête peut attraper cette erreur pour personnaliser la réponse. L'environnement d'exécution donne au gestionnaire de requête un peu plus de temps (moins d'une seconde) après avoir lever l'exception pour préparer cette réponse personnalisée.

Tandis qu'une requête peut prendre jusqu'à 30 secondes pour répondre, App Engine est optimisé pour les applications avec des requêtes de courtes durées, typiquement celles qui prennent quelques centaines de milliseconds. Une application efficace répond rapidement à la majorité des requêtes. Une application qui ne le ferait pas ne supportera pas bien la montée en charge sur l'infrastructure App Engine.

Le bac à sable

Pour permettre à App Engine de distribuer des requêtes pour des applications à travers de multiples serveurs web, et de prévenir une application d'interférer avec une autre, l'application s'exécute dans un environnement restreint ("sandbox"). Dans cet environnement, l'application peut exécuter du code, enregistrer et rechercher des données dans la base de données ("App Engine datastore"), utiliser la messageire App Engine, le rappatriement d'URL et les services utilisateurs, et examiner la requête utilisateur et préparer la réponse.

Une application App Engine ne peut pas:

Les Threads

Une application Java ne peut pas créer un nouveau java.lang.ThreadGroup ni un nouveau java.lang.Thread. Ces restrictions s'appliquent également aux classes JRE qui utilisent les threads. Par exemple, une application ne peut pas créer un nouveau java.util.concurrent.ThreadPoolExecutor, ni un java.util.Timer. Une application peut réaliser des opérations sur le thread courant, tel que Thread.currentThread().dumpStack().

Le Système de Fichiers

Une application Java ne peut pas utiliser les classes utilisées pour écrire sur le système de fichiers, telle que java.io.FileWriter. Une application peut lire ses propres fichiers sur le système de fichiers en utilisant les classes telle que java.io.FileReader. Une application peut aussi accèder à ses propres fichiers comme "ressources", tels que Class.getResource() ou ServletContext.getResource().

Seuls les fichiers considérés comme "fichiers ressources" sont accessibles depuis l'application via le système de fichiers. Par défaut, tous les fichiers dans le WAR sont des "fichiers ressources". Vous pouvez exclure des fichiers de cet ensemble en utilisant le fichier appengine-web.xml.

java.lang.System

Les caractéristiques de la classe java.lang.System qui ne satisfont pas à App Engine sont désactivées.

Les méthodes System suivantes ne font rien dans App Engine: exit(), gc(), runFinalization(), runFinalizersOnExit()

Les méthodes System suivantes retournent null: inheritedChannel(), console()

Une application ne peut pas fournir ou directement invoquer n'importe quel code natif JNI. Les méthodes System suivantes déclenchent une exceptionjava.lang.SecurityException: load(), loadLibrary(), setSecurityManager()

Réflexion

Une application dispose d'un accès complet, non restrictif, réflexif sur ses propres classes. Elle peut chercher n'importe quel membre privé, utiliser java.lang.reflect.AccessibleObject.setAccessible(), et lire/écrire des membres privés.

Une application peut aussi faire de la réflexion sur les classes JRE et API, telles que java.lang.String and javax.servlet.http.HttpServletRequest. Cependant, elle peut accèder seulement aux membres publiques de ces classes, pas aux protégés, ni aux privés.

Une application ne peut pas utiliser la réflexion sur n'importe quelles autres classes qui ne provient pas d'elle, et elle ne peut pas utiliser la méthode setAccessible() pour contourner ces restrictions.

Custom Class Loading

Le chargement de classes personnalisées est entièrement supporté sous App Engine. Cependant, veuillez noter que App Engine surcharge tous les ClassLoaders pour assigner les mêmes permission à toutes les classes chargées par votre application. Si vous chargez des classes personnalisées, faites attention lorsque vous chargez du code tiers non certifié.

La Liste Blanche du JRE

L'accès aux classes dans la librarie standard Java (l'Environnement d'Exécution Java, ou JRE) est limité aux classes spécifiées dans la liste blanche du JRE de App Engine.

Logging

Votre application peut écrire des informations dans les logs de l'application en utilisant java.util.logging.Logger. Les données de Log de votre application peuvent être visualisées et analysées en utilisant la Console d'Administration, ou téléchargées en utilisant appcfg.sh request_logs. La Console d'Administration peut reconnaitre les niveaux de logs de la classe Logger, et afficher de façons interactives les messages de différents niveaux.

Tout ce qu'une servlet écrit sur le flux de sortie standard (System.out) et le flux d'erreur standard (System.err) est capturé par App Engine et enregistré dans les logs de l'application. Les lignes écrites sur le flux de sortie standard sont loguées au niveau "INFO", et les lignes écrites sur le flux d'erreur standard sont loguées au niveau "WARNING". N'importe quel framework de log (tel que log4j) qui logue le flux de sortie standard ou le flux d'erreur standard fonctionnera. Cependant, pour plus de précisions de contrôle de l'affichage du niveau de log de la Console d'Administration, le framework de log doit utiliser un adaptateur java.util.logging.

import java.util.logging.Logger;
// ...

public class MyServlet extends HttpServlet {
    private static final Logger log = Logger.getLogger(MyServlet.class.getName());

    public void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws IOException {

        log.info("An informational message.");

        log.warning("A warning message.");

        log.severe("An error message.");
    }
}

Le SDK Java App Engine inclut un fichier modèle logging.properties, dans le répertoire appengine-java-sdk/config/user/. Pour l'utiliser, copier le fichier dans votre répertoire WEB-INF/classes (ou n'importe où dans le WAR), puis la propriété système java.util.logging.config.file dans "WEB-INF/classes/logging.properties" (ou n'importe quel chemin relatif à la racine de l'application que vous choisissez). Vous pouvez spécifier les propriétés dans le fichier appengine-web.xml, comme suit:

<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
    ...

    <system-properties>
        <property name="java.util.logging.config.file" value="WEB-INF/classes/logging.properties" />
    </system-properties>

</appengine-web-app>

Le Plugin Google pour Eclipse permet de lancer un assistant de création de projet. Celui-ci crée ces fichiers de configuration de logs pour vous, et les copie automatiquement dans WEB-INF/classes/. Pour java.util.logging, vous devez spécifier la propriété système pour utiliser ce fichier.

L'Environnement

Toutes les propriétés systèmes et les variables d'environnements sont privées à votre application. Spécifier une propriété système affecte seulement la vue qu'a l'application de cette propriété, et pas la vue de la JVM.

Vous pouvez spécifier des propriétés systèmes et les variables d'environnement pour votre application dans le déscripteur de déploiement.

App Engine spécifie les propriétés systèmes suivantes quand il initialise la JVM sur le serveur d'application:

Quotas et Limites

Chaque requête entrante dans l'application est comptabilisée dans le quota des Requêtes

Les données reçues en tant que requêtes sont comptabilisées dans le quota Bande Passante Entrante (facturable). Les données envoyées en réponse à une requête sont comptabilisées dans le quota Bande Passante Sortante (facturable).

Les requêtes HTTP et HTTPS (sécurisées) sont comptabilisées dans les quotas Requêtes, Bande Passante Entrante (facturable) et Bande Passante Sortante (facturable). La page des Détails des Quotas de la Console d'Administration indiquent également les valeurs Requêtes Sécurisées, Bande Passante Entrante Sécurisée and Bande Passante Sortante Sécurisée en qualité d'informations. Seules les requêtes HTTPS sont comptabilisées dans ces valeurs.

Le temps CPU utilisé pour traiter une requête est comptabilisé dans le quota Temps CPU (facturable).

Pour plus d'information sur les quotas, consultez Les Quotas, et la section "Les Détails des Quotas" de La Console d'Administration.

En plus des quotas, les limites suivantes s'appliquent aux gestionnaires de requêtes:

Limite Nombre
taille de requête 10 Mo
taille de requête 10 Mo
durée de requête 30 secondes
requêtes dynamiques simultanées 30 *
nombre maximum de fichiers applicatifs 1 000
nombre maximum de fichiers statiques 1 000
taille maximale d'un fichier applicatif 10 Mo
taille maximale d'un fichier statique 10 Mo
taille maximale totale de toute l'application et des fichiers statiques 150 Mo

* Une application peut exécuter environ 30 requêtes actives dynamiques simultanément. Cela signifie qu'une application dont le temps moyen de traitement de requête du côté serveur est 75 millisecondes peut servir jusqu'à (1000 ms/seconde / 75 ms/requête) * 30 = 400 requêtes/seconde sans subir de latences supplémentaires. Les applications qui sont fortement consommatrices de CPU peuvent subir des latences supplémentaires pour les longues requêtes de sorte à laisser s'exécuter les autres applications qui partagent les mêmes serveurs. Les requêtes concernant les fichiers statiques ne sont pas concernés par cette limite.

Téléchargements

Pour débuter

Java

Google Groupes
S'abonner au groupe
GAE en français
Email: