Abstract

DFC 5.x uses the session manager to pool sessions. Sessions need to be obtained from the session manager and then released back to the session manager. If sessions are not released back to session manager, session leaks can occur. This tip looks at means of detecting such session leaks. The tip is only for DFC 5.2.5 SP2 and higher versions.

Software Environment

Session Leaks

Session leaks can result when a caller does not return a session back to the pool. If a session is not released back to the pool, the session manager cannot reuse it. Thus, if a new request for a session comes in, session manager will have to create a new session. If this goes on for an extended period of time, a large number of unusable sessions will be created and eventually DFC will run out of sessions. This makes it important to find the source of session leaks.

Avoiding Session Leaks

Ideally, sessions should be obtained and released within a method body. The IDfSessionManager#getSession(...) and IDfSessionManager#release() are low overhead method calls and can be safely used within a method body. An IDfSession object should not be stored in a place where its release cannot be guaranteed. Thus, its not a good idea to store it as a class member variable or store it in some sort of a cache.

void myMethod() { IDfSession sess = null; IDfSessionManager sessMgr = .... try { .... sess = sessMgr.getSession(docbaseName); .... } finally { if(sess != null) { sessMgr.release(sess); } } }

Configuration

Base Configuration

• Open the $DOCUMENTUM\config\dfc.properties file. On our machine this file was in the c:\Documentum\config folder.
• To this file add the following line - dfc.resources.diagnostics.enabled=true .
• Save and close the dfc.properties file.
• Now open the $DOCUMENTUM\config\log4j.properties file. On our machine this file was in the c:\Documentum\config folder.
• Modify the property 'log4j.rootCategory' so that it looks like log4j.rootCategory=ERROR, stdout, file
• In the above line 'file' is a log4j appender that pipes the output to the file wdk.log. To verify this look for a line that looks something like log4j.appender.file.File=C\:/Documentum/logs/wdk.log . The actual path of the file may differ on your machine
• This should pipe the session leaks to the file wdk.log

Further Refinement

We can further refine this so that all the session leaks are piped to a special file. For this, do not modify the 'log4j.rootCategory' property. Instead add a new log4j appender. Thus, add the following lines in your log4j.properties file

log4j.logger.com.documentum.fc.client.DfSessionLeakChecker=ERROR,SESS_LEAK_DETECT log4j.appender.SESS_LEAK_DETECT=org.apache.log4j.RollingFileAppender log4j.appender.SESS_LEAK_DETECT.File=C\:/Documentum/logs/sessLeakDetector.log log4j.appender.SESS_LEAK_DETECT.MaxFileSize=100MB log4j.appender.SESS_LEAK_DETECT.MaxBackupIndex=5 log4j.appender.SESS_LEAK_DETECT.layout=org.apache.log4j.PatternLayout log4j.appender.SESS_LEAK_DETECT.layout.ConversionPattern=%d{ABSOLUTE} [%t] %m%n

The above will direct all output from the class com.documentum.fc.client.DfSessionLeakChecker to the file specified in the line log4j.appender.SESS_LEAK_DETECT.File=C\:/Documentum/logs/sessLeakDetector.log

Note:The DfSessionLeakChecker is an internal DFC class

Examining a session leak

Here is a sample leak

15:09:38,803 [Resource Housekeeper] DFC_BOF_SESSION_LEAK| Unreleased session found in finalize "docbase=wdk52no, refCounter=2, transFlag=false Session =com.documentum.fc.client.DfSession@19ee8a". com.documentum.fc.client.DfSessionLeakException at com.documentum.fc.client.DfSessionLeakChecker.<init>(DfSessionManager.java:1186) at com.documentum.fc.client.DfSessionManager.createRequiredSessionObject(DfSessionManager.java:513) at com.documentum.fc.client.DfSessionManager.getSession(DfSessionManager.java:507) at com.documentum.fc.client.DfSessionManager.getSession(DfSessionManager.java:283) >> at com.documentum.custom.test.TestDFCDiag.onClickHello(TestDFCDiag.java:41) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at com.documentum.web.form.FormProcessor.doInvokeMethod(FormProcessor.java:1168) at com.documentum.web.form.FormProcessor.invokeMethod(FormProcessor.java:938) at com.documentum.web.form.FormProcessor.fireActionEvent(FormProcessor.java:769) at com.documentum.web.form.RecallOperation.execute(RecallOperation.java:98) at com.documentum.web.form.FormProcessor.openForm(FormProcessor.java:136) at com.documentum.web.form.WebformTag.doStartTag(WebformTag.java:125) at org.apache.jsp.testDFCDiag_jsp._jspx_meth_dmf_webform_0(testDFCDiag_jsp.java:69) at org.apache.jsp.testDFCDiag_jsp._jspService(testDFCDiag_jsp.java:46) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137) ......

The stack trace will tell you the exact class from which the leak originated. In the above trace, the line marked with a '>>' tells the location of the leak. Note that the '>>' marking is not a part of the trace. You will need to go through the stack traces to find out the exact source of leak.

Performance

As the name implies, this mode is used to diagnose session related issues. It can impact performance and should be preferably used on development/test systems instead of production systems.

Bugs or Comments

If you find bugs or issues with the component/article, please contact developer_program@documentum.com with a short description of the issue, steps to reproduce it and the relevant software environment.