Compruebe y analice si la sesión de JCR se filtra en la instancia de AEM

Descripción

Compruebe si la aplicación AEM6.x tiene una fuga de sesión JCR y rastree el origen

Entorno

AEM 6.4,6.5

Resolución

Pasos

I. COMPRUEBE SI HAY UNA PÉRDIDA DE SESIÓN

  1. Vaya a http://host:port/system/console/jmx and inicie sesión como administrador.

  2. Utilice la función de búsqueda del explorador para buscar todas las ocurrencias de objetos SessionStatistics en la página.

  3. Si encuentra más de 500, entonces hay una fuga de sesión.

II. IDENTIFICAR EL CÓDIGO QUE ESTÁ PASANDO SESIONES

Si encuentra una fuga de sesión, siga los pasos a continuación para encontrar qué la está causando.

  1. Desplácese hacia abajo por la página hasta los objetos SessionStatistics.

  2. Abra algunos de los objetos de SessionStatistics en una nueva pestaña del explorador mediante [Ctrl]+Haga clic en algunas que tengan una marca de tiempo posterior o un número de identificación superior en la lista.  Por ejemplo, el de abajo tiene un id de

12105:org.apache.jackrabbit.oak "SessionStatistics" "admin@session-12105@Aug 10, 2020 7:03:25 PM" {id=287}. Cuanto mayor sea el número de identificación, más tarde se creará la sesión después del último AEM de reinicio.

  1. Revise los trazos de la pila mostrando qué código abrió esas sesiones.

  2. Busque paquetes java de aplicación en la pila.  Si el código forma parte de su aplicación, consulte la siguiente sección a continuación.

III. CORREGIR LA FUGA DE SESIÓN

Para evitar y corregir fugas en la sesión de JCR:

  • Si abre un javax.jcr.Session en su código, cierre siempre mediante Session.logout()

  • Si abre un org.apache.sling.api.resource.ResourceResolver en su código, cierre siempre mediante ResourceResolver.close()

Objetos de la sesión de cierre:

El código siguiente deja una sesión abierta:

try { Session session = repository.loginAdministrative(null); Nodo = session.getNode("/content/we-retail");   log.info("Node: " + node.getPath()); } catch (RepositoryException re)

Nota: Además de cerrar la sesión, este código también llama a repository.loginAdministrative para abrirla. Esta forma de abrir sesiones ha quedado obsoleta en versiones posteriores de AEM por motivos de seguridad.

Para cerrar la sesión, envuelva el código con un bloque try/finally y llame a session.logout():

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

Tenga cuidado al crear una sesión o compartirla.  Cuando comparta una sesión entre objetos, será más difícil rastrear dónde se abrió y cuándo se tiene que cerrar.  Además, las sesiones nunca deben compartirse entre subprocesos de Java.

Cerrando objetos ResourceResolver:

El código siguiente deja un ResourceResolver abierto:

try{ ResourceResolver resourceResolver = resourceFactory.getServiceResourceResolver(paramMap);   Recurso de recurso = resourceResolver.getResource("/content/we-retail");   log.info("Resource: " + res.getPath()); } catch(Exception e)

Para cerrar resourceResolver, ajuste el código con un bloque try/finally y llame a resourceResolver.close():

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

Nota importante

Los objetos Session y ResourceResolver que se obtienen mediante SlingRequest o WorkflowSession no deben ser cerrados por la aplicación.  Por ejemplo:

slingRequest.getResourceResolver().adaptTo(Session.class); //O workflowSession.getSession();

La resolución y la sesión se cerrarán automáticamente una vez que se haya procesado la solicitud.

En esta página