Analyse des sessions non déconnectées

Symptômes

Si vous rencontrez les situations suivantes, le problème peut être dû à des sessions non déconnectées dans CRX :

• Le système est de plus en plus lent.
• De temps à autre, la mémoire du système s'arrête de fonctionner (quelques heures, jours ou semaines selon la gravité).
• Version plus ancienne de CRX : vous disposez d'une grande quantité d'entrées « CacheManager: resizeAll » dans le fichier journal (le nombre derrière la taille correspond au nombre de caches; chaque session ouvre un certain nombre de caches).

Cause

Si une application ouvre CRXSessions, il incombe au développeur de garantir la fermeture appropriée de ces sessions. Si ce n'est pas le cas, ces sessions ne feront pas l'objet d'une récupération et resteront donc en mémoire. Chaque classe CRXSession crée et conserve son propre jeu de caches qui s’ajoute à la consommation de ressources globale.

Analyse

Pour indiquer un problème réel avec des sessions non déconnectées, exécutez les commandes pour déterminer le nombre total de CRXSessions actuel gardé en mémoire :

• jmap -histo:live <pid> | grep CRXSessionImpl

La deuxième colonne de la sortie correspond au nombre d’instances, ce qui signifie que de nombreuses sessions ne sont pas déconnectées (et sont donc encore gardées en mémoire). Si ce nombre est nettement supérieur à 100, alors c'est qu'il y a un problème avec CRXSessions dans votre application.

Pour voir combien d’objets CRXSession sont gardés en mémoire, y compris ceux qui sont en attente, exécutez la commande ci-dessous :

• jmap -histo <pid> | grep CRXSessionImpl

Comme pour la commande précédente, la deuxième colonne correspond au nombre d’instances.  Cela vous indique le nombre d’objets de session gardés en mémoire, dont la mémoire est en direct ou qui n'ont pas encore été nettoyés.  Ce nombre, par opposition au précédent, peut vous signaler que vous ouvrez et fermez trop de sessions CRX dans votre application.

Si vous exécutez CRX2.3 ou CQ5.5, vous pouvez forcer le nettoyage complet de la mémoire jvm en accédant à http://<host>:<port>/system/console/memoryusage et en cliquant sur le bouton « Nettoyer la mémoire ».  Après cela, vous pouvez à nouveau exécuter la commande ci-dessus quelques fois pour voir à quel point le nombre d’objets session augmente.  Cela vous permettra de savoir si votre application ouvre et ferme trop de sessions ou si vous devez régler vos paramètres gc.  En règle générale, si c'est un réel problème, vous remarquerez que la récupération de place jvm s'arrête, et que les performances sont ralenties lors d'opérations de sauvegarde au référentiel.

Remarque : l’application de ligne de commande jmap est fournie avec le JDK java et peut être trouvée dans le répertoire bin du jdk home.

Résolution

Pour résoudre ce problème, une analyse supplémentaire est nécessaire pour savoir qui ouvre réellement des sessions CRX et plus encore, ne les ferme pas. A partir de la version 1.4.1, le CRX s'accompagne d'un mode de débogage intégré qui permet de déceler les codes défectueux. En dépit de ce mode de débogage, il est possible de purger une trace de pile complète vers le fichier journal chaque fois qu’une session CRX est ouverte. Il consigne également une entrée chaque fois qu’une session CRX est fermée.

Pour activer le mode débogage de la session, ajoutez le paramètre JVM suivant au démarrage de CRX :

• -Dcrx.debug.sessions=true

REMARQUE : Selon l'utilisation du système, le fichier journal peut évoluer très rapidement.

Lors de l’utilisation du démarrage rapide, l’option -nofork doit être utilisée pour garantir l’utilisation de la propriété système.

Dès que vous recueillerez suffisamment de traces de pile (il est plus facile d'analyser le problème s'il existe au moins 1000 sessions non fermées), veuillez arrêter cette instance et supprimer le paramètre JVM. Le fichier journal (journal de sortie ou error.log en fonction de la version utilisée) contient les messages suivants, ainsi que les traces de pile :

• com.day.crx.core.CRXSessionImpl session# 193 opened

Exécutez le fichier joint avec la commande suivante :

• java -jar session_analyzer.jar <log_file> | sort > output.txt

Ainsi, un nouveau fichier output.txt contenant la trace de la pile des sessions fermées, triées par le contenu de trace de la pile. Chaque trace de pile forme une ligne « compressée » (les préfixes répétés sont supprimés). L’identifiant de session se trouve à la fin de la ligne.

Exemple :

com.day.crx.j2ee.JCRExplorerServlet.login(JCRExplorerServlet.java:521) ResourceServlet.spoolResource(ResourceServlet.java:148) java.lang.Thread.run(Thread.java:595): session# 10023

Cet exemple indique que la session #10023 n'a pas été fermée et la trace de la pile comprenait des lignes données lorsque la session était ouverte.

En fonction de cet fichier texte, vous devriez trouver l’emplacement du code défectueux et résoudre le problème. Si vous avez trouvé un défaut dans le code de base du produit, veuillez soumettre un ticket Daycare avec les informations collectées ci-dessus.

Application

CRX 1.3.x (veuillez demander un patch si vous devez analyser le problème)
CRX 1.4.x (pour la 1.4.0 vous devez installer le correctif en pièce jointe)
CRX 2.x