Analizar sesiones no cerradas

Síntomas

Si usted experimenta las siguientes condiciones, el problema podría deberse a sesiones no cerradas en CRX:

• El sistema se vuelve cada vez más lento
• De vez en cuando el sistema se queda sin memoria (después de unas pocas horas, días o semanas, dependiendo de la gravedad)
• Versión anterior de CRX: tiene muchas entradas “CacheManager: resizeAll” en el archivo de registro (el número detrás de size=.... es el número de cachés; cada sesión abre unos cuantos cachés)

Causa

Si una aplicación abre las CRXSessions de forma explícita, es responsabilidad del desarrollador garantizar el cierre adecuado de estas sesiones. De lo contrario, tales sesiones no serán objeto de recolección de basura y por lo tanto permanecerán en la memoria, causando los síntomas mencionados anteriormente. Cada CRXSession crea y mantiene su propio conjunto de cachés, lo que se suma al consumo total de recursos.

Análisis

Para identificar un problema real con las sesiones no cerradas, ejecute los siguientes comandos para determinar el número total de CRXSessions que se mantienen en memoria:

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

La segunda columna de la salida es el recuento de instancias, lo que significa que muchas sesiones no están cerradas (y en realidad residen en memoria). Si este número es significativamente más alto que 100, entonces hay un problema con CRXSessions en su aplicación.

Para ver cuántos objetos CRXSession se guardan en la memoria, incluidos los que esperan ser recogidos, ejecute el siguiente comando:

• jmap -histo <pid> | grep CRXSessionImpl

Al igual que con el comando anterior, la segunda columna es el recuento de instancias.  Esto le indica cuántos objetos de sesión hay en la memoria que están vivos o que aún no han sido recogidos.  Este número, en comparación con el anterior, puede indicarle si está abriendo y cerrando demasiadas sesiones CRX en su aplicación.

Si está ejecutando CRX2.3 o CQ5.5, puede forzar una recogida de residuos completa de jvm yendo a http://<host>:<port>/system/console/memoryusage y haciendo clic en el botón Ejecutar recogida de residuos.  Después de hacer esto, puede volver a ejecutar el comando anterior varias veces para ver qué tan rápido aumenta el número de objetos de sesión.  Esto le dará una idea de si su aplicación está abriendo y cerrando demasiadas sesiones o si necesita ajustar la configuración de su gc.  Normalmente, si esto es realmente un problema, notará grandes pausas en la recolección de basura de jvm y un rendimiento lento durante las operaciones de guardar en el repositorio.

Nota: La aplicación de línea de comandos jmap se envía con el JDK de Java y se puede encontrar en el directorio home bin de jdk.

Resolución

Para resolver este problema, se requiere un análisis más profundo para averiguar quién abre realmente las CRXSessions y, lo que es más importante, quién no las cierra. A partir de 1.4.1, CRX viene con un modo de depuración incorporado que le permite rastrear el código de defecto. Lo que este modo de depuración hace básicamente es volcar una traza de pila completa al archivo de registro de salida estándar cada vez que se abre un CRXSession. También registra una entrada cada vez que se vuelve a cerrar una CRXSession.

Para habilitar el modo de depuración de sesión, añada el siguiente parámetro JVM al iniciar CRX:

• -Dcrx.debug.sessions=true

NOTA: Dependiendo del uso del sistema, el archivo de registro puede crecer rápidamente.

Cuando se utiliza el inicio rápido, se debe utilizar la opción -nofork para asegurarse de que se utiliza la propiedad del sistema.

Tan pronto como haya reunido suficientes trazas de la pila (es más fácil analizar el problema si hay al menos 1000 sesiones no cerradas), detenga la instancia y elimine de nuevo el parámetro JVM. El archivo de registro (registro de salida del sistema o error.log dependiendo de la versión utilizada) contendrá los siguientes mensajes, además de trazas de pila:

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

Luego ejecute el archivo jar adjunto con el siguiente comando:

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

Esto generará un nuevo archivo output.txt que contiene la traza de la pila de sesiones no cerradas, ordenadas por el contenido de la traza de la pila. Cada trazo de pila es una línea, y “comprimido” un poco (se eliminan los prefijos repetidos). El identificador de sesión se encuentra al final de la línea.

Ejemplo:

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

Este ejemplo significa que la sesión #10023 no se cerró, y que la traza de la pila incluía las líneas dadas cuando se abrió la sesión.

Basado en esta salida usted debería ser capaz de encontrar la ubicación del código de defecto y arreglar el problema. En caso de que haya encontrado un defecto en nuestro código de producto, abrir un vale a soporte junto con la información recopilada anteriormente.

Aplica

CRX 1.3.x (pida un parche si necesita analizar el problema)
CRX 1.4.x (para 1.4.0 necesita instalar la corrección del archivo adjunto)
CRX 2.x