You are looking at documentation for an older release. Not what you want? See the current release documentation.
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, it will suspect that many sessions are leaked although they are not. The default max age value is configured at 2 minutes.
Setting the exo.jcr.session.tracking.active virtual machine system property 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.session.tracking.maxage
in seconds. The default value is 120 (2 minutes) if you do not override.
For example, you can do this easily in start_eXo.sh.
On Linux/Macs:
JCR_SESSION_TRACK="-Dexo.jcr.session.tracking.active=true -Dexo.jcr.session.tracking.maxage=60" JAVA_OPTS="$JCR_SESSION_TRACK $JAVA_OPTS $LOG_OPTS $SECURITY_OPTS $EXO_OPTS $EXO_CONFIG_OPTS $REMOTE_DEBUG"
On Windows:
set JCR_SESSION_TRACK=-Dexo.jcr.session.tracking.active=true -Dexo.jcr.session.tracking.maxage=60 set JAVA_OPTS="%JCR_SESSION_TRACK% %JAVA_OPTS% %LOG_OPTS% %SECURITY_OPTS% %EXO_OPTS% %EXO_CONFIG_OPTS% %REMOTE_DEBUG%"
Activate the session tracking and configure a maxage of 1 minute. Any JCR session older than 1 minute will cause an alert.
Each detector execution starts with
Starting detector task
and ends with
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.
For example:
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)
...
In this Stacktrace, you learn that the org.exoplatform.faq.service.impl.JCRDataStorage.getFAQServiceHome method 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).