IBM on troubleshooting Java applications

The general guidance is that the data stored in an HTTP session should only be used to store the necessary data to main state between browser invocations, and that the amount of data stored should be as small as possible. However we often see that, over several iterations of additional development work and new features being added to a web application, the session sizes have grown as more and more data is being stored.

This means the corresponding session cache also grows over time, in some cases to the point that it is one of the major contributors to the Java heap memory usage.

So, are there any ways to find out how big the sessions are?

Find the session sizes using the Runtime Performance Advisor of the Tivoli Performance Viewer (TPV)

You can use either the Runtime Performance Advisor in the administrative console, or the Tivoli Performance Viewer (TPV) to look at the session cache size and the average session size, so this will give you an idea if you have a problem with the size of HTTP sessions and the corresponding size of session cache required.
Neither the Performance Advisor or TPV give you a good idea of application or which specific user sessions are large, of what specific data is being held in the HTTP sessions, which is useful if you want to understand whether its particular applications or actions that are causing large amounts of data to be stored, and in fact what that data is.

Investigating HTTP sessions using IBM Monitoring and Diagnostic Tools for Java - Memory Analyzer

Having information on the sizes of individual sessions, what the user session ID is, and what application the session is for will allow you to understand whether the presence of large HTTP sessions is related to a specific application, or a specific set of user actions. One way of getting this information is using Memory Analyzer.

Memory Analyzer can run using either a PHD format heapdump, or a full operating system dump (eg. a core file) that has been post processed using the "jextract" utility that is present in the jre/bin directory of the IBM Java SDKs. In order have the information relating to application name and session ID for the HTTP sessions, the jextracted system dump is required.
You can generate a system dump from a running WebSphere instance by adding the following command line option to the JVM runtime:

	-Xdump:system:events=user

and then sending a "kill -3" to the process to cause the dump to be written (you can do this in Windows using a utility such as sendsignal.exe). Alternatively you can generate the system dump on an OutOfMemoryError using the following:

	-Xdump:system:events=systhrow,filter=java/lang/OutOfMemoryError

Once you have the system dump, its been processed using jextract, and is loaded into Memory Analyzer, you can begin profiling the HTTP sessions.

Profiling the HTTP session sizes using OQL in Memory Analyzer

You can use the Object Query Language (OQL) in Memory Analyzer to quickly produce a table of all of the sessions that were in the WebSphere instance when the system dump was generated, along with information on: session size, application name, and session id.

To do this you need to:

1. Select the OQL tab from the analysis panel:
This opens the OQL dialog box
2. Enter the following OQL:

	SELECT 	data as "MemorySessionData", 
			data.@usedHeapSize as "Heap Size", 
			data.@retainedHeapSize as "Retained Heap Size", 
			mSwappableData, 
			toString(data.mManager.scAppParms._J2EEName) as "J2EE Name", 
			toString(data.appName) as "App Name", 
			toString(data.mSessionId) as "Session ID" 
	FROM com.ibm.ws.webcontainer.httpsession.MemorySessionData data

This should produce a table of the MemorySessionData objects
3. Sort by Retained Heap Size by clicking on the column header
This will show you the largest session data objects, along with the app name and session ID. The session ID for the user will either be available from the URL, or in a cookie

This means that you now have a sortable table of sessions and how they relate to specific applications and session IDs.

Finding out what values are stored in specific HTTP sessions

If you identify specific sessions that are larger than expected, and you want to understand what data is being stored in that session, you have the option of "drilling down" into the session and looking at the key/value pairs for the data in the sessions.

To do this you need to:

1. Right click on a row of interest and select "List objects -> with outgoing references"
This will bring up the individual MemorySessionData object
2. Expand the object down the following reference path: "mSwappableData -> table"
This gives you the Hashtable of data associated with the session.

You can now browse through the Hashtable, looking at the keys and values to see what data is being stored inside the session, and what is causing the session to be so large!