Session Invalidation results in memory leak in clustered environments.
 Technote (troubleshooting)
 
Problem(Abstract)
Session Invalidation considerations and how this can lead to memory leaks
 
Cause
When valueUnbound method is not coded to be jvm independent, memory leak can occur.
 
Resolving the problem

Considerations when coding valueUnbound method in a clustered environment.

ValueUnbound method is called on objects implementing HttpSessionBindingListener interface when a session is invalidated.

In a distributed environment, timed out sessions can be invalidated by any JVM.

Sessions created in one jvm may be invalidated by another.

As a result, the valueUnbound method can run in a different JVM than the session was created it.

Consequently, the valueUnbound method should not be used to perform jvm dependent tasks(such as object cleanup) as it will lead to memory leaks.

Tasks performed by valueUnbound method should be JVM independent.

Overview of session invalidation

When sessions are invalidated:

Sessions are invalidated either by the application code or by the WebSphere invalidation thread after a session invalidation timeout has been reached. Session invalidation time out is configured in the WebContainer session manager.

(Default 30 min)

Invalidation Thread.

By default the WebSphere invalidation thread runs at 5 minute intervals.

The job of the invalidation thread is to locate and remove timed out session objects from jvm cache or the session persistence mechanism(database/mem to mem).

For versions 4.x and 5.x the invalidation thread can be located in jvm thread dumps by searching for the following package,class, and method:

com.ibm.servlet.personalization.sessiontracking.SessionContextRegistry.run

When persistence is not enabled, session invalidation performs the task of cleaning up timedout sessions from cache (jvm heap)

With persistence, the invalidation thread goes to the session database to interrogate whether the session object is a candidate for invalidation.

When a session object is invalidated, all listeners are called in the JVM that the invalidation takes place. For example, if an object in the session implements the HttpSessionBindingListener interface, the valueUnbound method will be called in the JVM that invalidates the session.

HttpSessionBindingListener

Session objects which object implement the HttpSessionBindingListener interface contain the following methods that will signal an object being bound into, or being unbound from, a session.
• valueBound
• valueUnbound
For more information see: http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/http/HttpSessionBindingListener.html

Troubleshooting memory leaks caused by implementing the HttpSessionBindingListener interface.

1) This type of leak is only present in a clustered environment and with session persistence enabled.

2) First verify the application objects value unbound methods ensure that tasks performed by valueUnbound method are JVM independent.

3) A JVM thread dump will contain a thread with a method present called:

com.ibm.servlet.personalization.sessiontracking.SessionContextRegistry.run

If this thread is not present, invalidation is not taking place.

4) Gather the following and invoke WebSphere support:

a) JVM thread dump

b) session trace

c) JVM heapdump

Specific information required by WebSphere support is available via the following links:

Session trace:
Version 4.x http://www.ibm.com/support/docview.wss?uid=swg21055373

Version 5.x Sessions_and_Session_Management/swg21083912.html

 
 
Cross Reference information
Segment Product Component Platform Version Edition
Application Servers Runtimes for Java Technology Java SDK
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Sessions and Session Management
Operating system(s): Windows
Software version: 5.1.1
Software edition:
Reference #: 1173385
IBM Group: Software Group
Modified date: Jun 30, 2004