Vérifier et analyser s’il existe une interruption de session dans l’instance AEM

AEM 6.x

1. Accédez à http://host:port/system/console/jmx et connectez-vous en tant qu’administrateur.
2. Utilisez la fonction de recherche du navigateur pour rechercher toutes les occurrences des objets SessionStatistics sur la page.
3. Si vous trouvez plus de 500, alors il y a une interruption de session.

Si vous avez trouvé une interruption de session, suivez les étapes ci-dessous pour trouver la cause :

1. Faire défiler la page vers les objets SessionStatistics.
2. Ouvrir certains des objets SessionStatistics dans un nouvel onglet du navigateur par [Ctrl]+Cliquer sur certains qui ont un horodatage ultérieur ou un numéro d’identification plus élevé.  Par exemple celui a ci-dessous un ID de 12105:org.apache.jackrabbit.oak "SessionStatistics" "admin@session-12105@Aug 10, 2016 7:03:25 PM" {id=287}. Plus le numéro d’identification est élevé, plus la session a été créée après le dernier redémarrage AEM.
3. Examiner les traces de pile qui indiquent quel code a ouvert ces sessions.
4. Rechercher des packages JavaScript d’application dans la pile.  Si le code fait partie de votre application, consulter la section suivante ci-dessous.

Pour empêcher et corriger les interruptions de session JCR :

• Après avoir ouvert javax.jcr.Session dans le code, fermez-le toujours via Session.logout().
• Après avoir ouvert org.apache.sling.api.resource.ResourceResolver dans le code, fermez-le toujours via ResourceResolver.close().

Fermeture d’Objets de session :

Le code ci-dessous quitte une session laissée ouverte :

try {
Session session = repository.loginAdministrative(null);
Node node = session.getNode("/content/geometrixx");
  log.info("Node: " + node.getPath());
} catch (RepositoryException re) {
log.error(re.getMessage(), re);
}

Pour fermer la session, enveloppez le code avec un bloc try/finally et appelez session.logout() :

Session session = null;
try {
session = repository.loginAdministrative(null);
// use session
} catch (RepositoryException re) {
log.error(re.getMessage(), re);
} finally {
if (session != null && session.isLive()) {
session.logout();
}
}

Soyez prudent lors de la création d’une session ou du partage d’une session.  Lorsque vous partagez une session sur plusieurs objets, il est plus difficile de suivre où elle a été ouverte et quand elle doit être fermée.  Par ailleurs, les sessions ne doivent jamais être partagées dans les threads Java.

Fermeture des objets ResourceResolver :

Le code ci-dessous laisse un ResourceResolver ouvert :

try{
ResourceResolver resourceResolver = resourceFactory.getServiceResourceResolver(paramMap);
  Resource resource = resourceResolver.getResource("/content/geometrixx");
  log.info("Resource: " + res.getPath());
} catch(Exception e){
log.error(e.getMessage());
}

Pour fermer le composant resourceResolver, enveloppez le code avec un bloc try/finally et appelez resourceResolver.close() :

try{
ResourceResolver resourceResolver = resourceFactory.getServiceResourceResolver(paramMap);
  // use ResourceResolver
} catch (Exception e) {
log.error(e.getMessage());
} finally {
if(resourceResolver != null && resourceResolver.isLive()) {
resourceResolver.close();
}
}

Les objets Session et ResourceResolver obtenus via SlingRequest ou WorkflowSession ne doivent pas être fermés par votre application.  Par exemple :

slingRequest.getResourceResolver().adaptTo(Session.class);
- Ou
workflowSession.getSession();

Ce résolveur et cette session sont automatiquement fermés après traitement de la demande.