Verifique e analise se a sessão JCR vazar em sua instância AEM

Verifique e identifique a causa do vazamento da sessão JCR do aplicativo AEM 6.x.

Descrição

Verifique se o aplicativo AEM 6.x tem um vazamento de sessão JCR e rastreie a origem.

Ambiente

AEM 6.4,6.5

Resolução

I. VERIFIQUE SE HÁ UM VAZAMENTO DE SESSÃO

1. Ir para http://host:port/system/console/jmx e faça logon como administrador.
2. Use o recurso de pesquisa do navegador para localizar todas as ocorrências de objetos SessionStatistics na página.
3. Se você encontrar mais de 500, então há um vazamento de sessão.

II. IDENTIFIQUE O CÓDIGO QUE ESTÁ VAZANDO SESSÕES

Se você encontrou um vazamento de sessão, siga as etapas abaixo para encontrar a causa.

1. Role a página para baixo até os objetos SessionStatistics.
2. Abra alguns dos objetos SessionStatistics em uma nova guia do navegador usando [Ctrl] +Clique em alguns que tenham um carimbo de data e hora posterior ou um número de id superior listado.  Por exemplo, o objeto abaixo tem uma ID de
3. 12105:org.apache.jackrabbit.oak "SessionStatistics" "admin@session-12105@Aug 10, 2020 7:03:25 PM" {id=287}.
4. Quanto maior o número de id, mais tarde a sessão será criada após a última reinicialização do AEM.
5. Revise os rastreamentos de pilha que mostram qual código abriu essas sessões.
6. Procure pacotes java de aplicativos na pilha.  Se o código fizer parte do aplicativo, consulte a próxima seção abaixo.

III. CORRIGIR O VAZAMENTO DA SESSÃO

Para evitar e corrigir vazamentos de sessão JCR:

• Se você abrir um javax.jcr.Session no código, sempre feche-o via Session.logout()
• Se você abrir um org.apache.sling.api.resource.ResourceResolver no código, sempre feche-o via ResourceResolver.close()

Objetos da sessão de fechamento:

O código abaixo deixa uma sessão aberta:

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

*Observação:*além de não apenas fechar a sessão, esse código também chama repository.loginAdministrative para abri-la. Essa maneira de abrir sessões foi descontinuada em versões posteriores do AEM por motivos de segurança.

Para fechar a sessão, você envolveria o código com um bloco try/finally e chamaria 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();
}
}

Tenha cuidado ao criar uma sessão ou compartilhá-la.  Quando você compartilha uma sessão entre objetos, fica mais difícil rastrear onde ela foi aberta e quando precisa ser fechada.  Além disso, as sessões nunca devem ser compartilhadas no Java Threads.

Fechando objetos ResourceResolver:

O código abaixo deixa um ResourceResolver aberto:

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

Para fechar resourceResolver, envolva o código com um bloco try/finally e chame 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();
  }
}

Observação importante

Os objetos Session e ResourceResolver que são obtidos por meio do SlingRequest ou WorkflowSession não devem ser fechados pelo seu aplicativo.  Por exemplo:

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

O resolvedor e a sessão serão fechados automaticamente após o processamento da solicitação.