Sélectionner vos préférences de cookies

Nous utilisons des cookies essentiels et des outils similaires qui sont nécessaires au fonctionnement de notre site et à la fourniture de nos services. Nous utilisons des cookies de performance pour collecter des statistiques anonymes afin de comprendre comment les clients utilisent notre site et d’apporter des améliorations. Les cookies essentiels ne peuvent pas être désactivés, mais vous pouvez cliquer sur « Personnaliser » ou « Refuser » pour refuser les cookies de performance.

Si vous êtes d’accord, AWS et les tiers approuvés utiliseront également des cookies pour fournir des fonctionnalités utiles au site, mémoriser vos préférences et afficher du contenu pertinent, y compris des publicités pertinentes. Pour accepter ou refuser tous les cookies non essentiels, cliquez sur « Accepter » ou « Refuser ». Pour effectuer des choix plus détaillés, cliquez sur « Personnaliser ».

Hooks d' SnapStart exécution Lambda pour Java

Mode de mise au point
Hooks d' SnapStart exécution Lambda pour Java - AWS Lambda

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Vous pouvez utiliser des hooks d’exécution pour implémenter du code avant que Lambda ne crée un instantané ou après que Lambda ait repris une fonction à partir d’un instantané. Les hooks d'exécution sont disponibles dans le cadre du projet open source Coordinated Restore at Checkpoint (CRaC). CRaC est en cours de développement pour le kit de développement Open Java (OpenJDK). Pour un exemple d'utilisation de CRa C avec une application de référence, consultez le référentiel CRaC sur GitHub. CRaC utilise trois éléments principaux :

  • Resource – Une interface avec deux méthodes, beforeCheckpoint() et afterRestore(). Utilisez ces méthodes pour implémenter le code que vous voulez exécuter avant un instantané et après une restauration.

  • Context <R extends Resource> – Pour recevoir des notifications pour les points de contrôle et les restaurations, une Resource doit être enregistrée avec un Context.

  • Core – Le service de coordination, qui fournit le Context global par défaut via la méthode statique Core.getGlobalContext().

Pour plus d'informations sur Context etResource, consultez Package org.crac dans la CRa documentation C.

Suivez les étapes suivantes pour implémenter des hooks d’exécution avec le package org.crac. Le moteur d'exécution Lambda contient une implémentation de contexte CRa C personnalisée qui appelle vos hooks d'exécution avant le point de contrôle et après la restauration.

Enregistrement et exécution du hook d’exécution

L’ordre dans lequel Lambda exécute vos hooks d’exécution est déterminé par l’ordre d’enregistrement. L’ordre d’enregistrement suit l’ordre d’importation, de définition ou d’exécution dans votre code.

  • beforeCheckpoint() : exécutés dans l’ordre inverse de l’enregistrement

  • afterRestore() : exécutés dans l’ordre d’enregistrement

Assurez-vous que tous les hooks enregistrés sont correctement importés et inclus dans le code de votre fonction. Si vous enregistrez les hooks d’exécution dans un fichier ou un module distinct, vous devez vous assurer que le module est importé, soit directement, soit dans le cadre d’un package plus large, dans le fichier de gestionnaire de votre fonction. Si le fichier ou le module n’est pas importé dans le gestionnaire de fonctions, Lambda ignore les hooks d’exécution.

Note

Lorsque Lambda crée un instantané, votre code d’initialisation peut s’exécuter jusqu’à 15 minutes. Le délai d’attente est de 130 secondes ou le délai d’expiration de la fonction configurée (900 secondes au maximum), la valeur la plus élevée étant retenue. Vos hooks d’exécution beforeCheckpoint() sont comptabilisés dans le délai d’attente du code d’initialisation. Lorsque Lambda restaure un instantané, l’exécution doit se charger et les hooks d’exécution afterRestore() doivent se terminer dans le délai imparti (10 secondes). Sinon, vous obtiendrez un SnapStartTimeoutException.

Étape 1 : mettre à jour de configuration de création

Ajoutez la dépendance org.crac à la configuration de compilation. L’exemple suivant utilise Gradle. Pour des exemples concernant d’autres systèmes de compilation, consultez la documentation Apache Maven.

dependencies { compile group: 'com.amazonaws', name: 'aws-lambda-java-core', version: '1.2.1' # All other project dependecies go here: # ... # Then, add the org.crac dependency: implementation group: 'org.crac', name: 'crac', version: '1.4.0' }

Étape 2 : mettre à jour le gestionnaire Lambda

Le gestionnaire de fonction Lambda est la méthode dans votre code de fonction qui traite les événements. Lorsque votre fonction est invoquée, Lambda exécute la méthode du gestionnaire. Votre fonction s’exécute jusqu’à ce que le gestionnaire renvoie une réponse, se ferme ou expire.

Pour de plus amples informations, veuillez consulter Définition du gestionnaire de fonction Lambda dans Java.

L’exemple de gestionnaire suivant montre comment exécuter le code avant le point de contrôle (beforeCheckpoint()) et après la restauration (afterRestore()). Ce gestionnaire enregistre également la Resource dans le Context global géré par l’environnement d’exécution.

Note

Lorsque Lambda crée un instantané, votre code d’initialisation peut s’exécuter jusqu’à 15 minutes. Le délai d’attente est de 130 secondes ou le délai d’expiration de la fonction configurée (900 secondes au maximum), la valeur la plus élevée étant retenue. Vos hooks d’exécution beforeCheckpoint() sont comptabilisés dans le délai d’attente du code d’initialisation. Lorsque Lambda restaure un instantané, l’exécution (JVM) doit se charger et les hooks d’exécution afterRestore() doivent se terminer dans le délai imparti (10 secondes). Sinon, vous obtiendrez un SnapStartTimeoutException.

... import org.crac.Resource; import org.crac.Core; ... public class CRaCDemo implements RequestStreamHandler, Resource { public CRaCDemo() { Core.getGlobalContext().register(this); } public String handleRequest(String name, Context context) throws IOException { System.out.println("Handler execution"); return "Hello " + name; } @Override public void beforeCheckpoint(org.crac.Context<? extends Resource> context) throws Exception { System.out.println("Before checkpoint"); } @Override public void afterRestore(org.crac.Context<? extends Resource> context) throws Exception { System.out.println("After restore");

Context maintient uniquement une WeakReference à l’objet enregistré. Si une Resource est récupérée par le récupérateur de mémoire, les hooks d’exécution ne s’exécutent pas. Votre code doit maintenir une référence forte à la Resource pour garantir l’exécution du hook d’exécution.

Voici deux exemples de modèles à éviter :

Exemple – Objet sans référence forte
Core.getGlobalContext().register( new MyResource() );
Exemple – Objets de classes anonymes
Core.getGlobalContext().register( new Resource() { @Override public void afterRestore(Context<? extends Resource> context) throws Exception { // ... } @Override public void beforeCheckpoint(Context<? extends Resource> context) throws Exception { // ... } } );

Au lieu de cela, maintenez une référence forte. Dans l’exemple suivant, la ressource enregistrée n’est pas récupérée par le récupérateur de mémoire et les hooks d’exécution s’exécutent de manière cohérente.

Exemple – Objet avec une référence forte
Resource myResource = new MyResource(); // This reference must be maintained to prevent the registered resource from being garbage collected Core.getGlobalContext().register( myResource );

Rubrique suivante :

Python

Rubrique précédente :

Hooks d’exécution
ConfidentialitéConditions d'utilisation du sitePréférences de cookies
© 2025, Amazon Web Services, Inc. ou ses affiliés. Tous droits réservés.