Session Leak Detector

Session Leak Detector

Introduction

The session leak detector is able to help you debug your application based on JCR when you suspect that you have a bug related to a wrong usage of JCR sessions. It works by creating a queue of weak references to JCR sessions and the queue is periodically cleaned. When a session reference is dequeued and is not cleared it is considered as a leaked session. Obviously what matters here is the time by which a session is stale known as max age. If the max age is too short period it will suspect that many sessions are leaked although they are not. The default max age value is configured at 2 minutes.

Activation

Setting the virtual machine system property exo.jcr.session.tracking.active to true activates the session detector with a default time period of 2 minutes.

You can set the max age with the virtual machine system property exo.jcr.jcr.session.tracking.maxage in seconds. The default value, if you don't override it is 120 (2 minutes).

Example :

You can do this easily in eXo.sh. For example : On Linux/Macs :

JCR_SESSION_TRACK="-Dexo.jcr.session.tracking.active=true -Dexo.jcr.jcr.session.tracking.maxage=60"
JAVA_OPTS="$JCR_SESSION_TRACK $JAVA_OPTS $LOG_OPTS $SECURITY_OPTS $EXO_OPTS $EXO_CONFIG_OPTS $REMOTE_DEBUG"

set JCR_SESSION_TRACK=-Dexo.jcr.session.tracking.active=true -Dexo.jcr.jcr.session.tracking.maxage=60
set JAVA_OPTS="%JCR_SESSION_TRACK% %JAVA_OPTS% %LOG_OPTS% %SECURITY_OPTS% %EXO_OPTS% %EXO_CONFIG_OPTS% %REMOTE_DEBUG%"

We activate the session tracking and configure a maxage of 1 minute. Any JCR session older than 1 minute will cause an alert.

Report

Each detector execution starts with

Starting detector task

Finished detector task

When a session is considered as leaked, debug information is printed on the console with a stack trace of the code that created the session in order to help you find out where the leaked session was created at runtime.

Example :

<expired>
java.lang.Exception
        at org.exoplatform.services.jcr.impl.core.SessionReference.<init>(SessionReference.java:113)
        at org.exoplatform.services.jcr.impl.core.TrackedXASession.<init>(TrackedXASession.java:32)
        at org.exoplatform.services.jcr.impl.core.SessionFactory.createSession(SessionFactory.java:128)
        at org.exoplatform.services.jcr.impl.core.RepositoryImpl.getSystemSession(RepositoryImpl.java:314)
        at org.exoplatform.services.jcr.impl.core.RepositoryImpl.getSystemSession(RepositoryImpl.java:71)
        at org.exoplatform.services.jcr.ext.common.SessionProvider.getSession(SessionProvider.java:157)
        at org.exoplatform.faq.service.impl.JCRDataStorage.getFAQServiceHome(JCRDataStorage.java:323)
        ...
</expired>

In this Stacktrace we learn that the method org.exoplatform.faq.service.impl.JCRDataStorage.getFAQServiceHome has opened a session that seems to be leaked. You need to verify in the code if Session.logout() is properly called in all cases (calling it in finally clause usually resolves the issue).