Verifique se o aplicativo AEM6.x tem um vazamento de sessão JCR e rastreie a origem
Ambiente
AEM 6.4,6.5
Etapas
I. VERIFIQUE SE HÁ UMA FALTA DE SESSÃO
Vá para http://host:port/system/console/jmx and fazer logon como administrador.
Use o recurso de pesquisa do navegador para localizar todas as ocorrências de objetos SessionStatistics na página.
Se você encontrar mais de 500, há um vazamento de sessão.
II. IDENTIFICAR O CÓDIGO QUE ESTÁ DEIXANDO SESSÕES
Se você encontrou um vazamento de sessão, siga as etapas abaixo para descobrir o que o está causando.
Role a página para baixo até os objetos SessionStatistics.
Abra alguns dos objetos SessionStatistics em uma nova guia do navegador [Ctrl]+Clicando em alguns que tenham um carimbo de data e hora ou um número de ID mais alto listado. Por exemplo, aquele abaixo tem uma id de
12105:org.apache.jackrabbit.oak "SessionStatistics" "admin@session-12105@Aug 10, 2020 7:03:25 PM" {id=287}. Quanto maior o número de identificação, mais tarde a sessão foi criada após a última reinicialização AEM.
Revise os rastreamentos de pilha que mostram qual código abriu essas sessões.
Procure por 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 do JCR:
Se você abrir um javax.jcr.Session em seu código, sempre feche via Session.logout()
Se você abrir um org.apache.sling.api.resource.ResourceResolver em seu código, sempre feche via ResourceResolver.close()
Fechamento de objetos da sessão:
O código abaixo deixa uma sessão aberta:
tente { Session session = repository.loginAdministrative(null); Nó = session.getNode("/content/we-retail"); log.info("Nó: " + node.getPath()); } catch (RepositoryException re)
Observação: Além de não apenas fechar a sessão, este 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, envolva o código com um bloco try/finally e chame session.logout():
Sessão = null; tente { session = repository.loginAdministrative(null); // use session } catch (RepositoryException re) { log.error(re.getMessage(), re); } finally { if (sessão != null && session.isLive())
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 ela deve ser fechada. Além disso, as sessões nunca devem ser compartilhadas entre os threads Java.
Fechamento de objetos ResourceResolver:
O código abaixo deixa um ResourceResolver aberto:
try{ ResourceResolver resourceResolver = resourceFactory.getServiceResourceResolver(paramMap); Recurso recurso = resourceResolver.getResource("/content/we-retail"); log.info("Recurso: " + res.getPath()); } catch(Exception e)
Para fechar o resourceResolver, envolva o código com um bloco try/finally e chame resourceResolver.close():
try{ ResourceResolver resourceResolver = resourceFactory.getServiceResourceResolver(paramMap); // use ResourceResolver } catch (Exceção e) { log.error(e.getMessage()); } finally { if(resourceResolver != null && resourceResolver.isLive())
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); //Ou workflowSession.getSession();
Esse resolvedor e sessão serão fechados automaticamente após o processamento da solicitação.