Determining the size of HTTP session in a Java web application

                                                                                                                                 -Shankar Tamma
This Knowledge Brief (KB) discusses a method of measuring the amount of memory consumed by the HTTP session in a Java web application.

In a Java web application it is often necessary to store data between HTTP requests from the client and this data is commonly stored in the HTTP session. By default most application servers store objects placed into the HTTP session in memory, although alternatives such as database storage are often provided.

If you have chosen to use in-memory storage, then you need to monitor the amount of memory consumed per client, so that you can ensure that the total memory used by all clients stays well within acceptable limits.

The Servlet Specification and API do not provide any methods which allow the session size to be determined directly, but fortunately the Java Web Parts library contains the functionality to determine session size.

Java Web Parts Library

The Java Web Parts (http://javawebparts.sourceforge.net/) library provides a simple and effective means of determining the size of the HTTP session. All you need to do to expose this functionality is to write a simple listener class as described below.

SessionSizeListener Class

The SessionSize class in the Java Web Parts library determines the total size of a single clients HTTP session in bytes. A session attribute listener (Figure 1) which delegates to the SessionSize class, allows monitoring of session size and can be deployed into any web application.

For this listener to work accurately, the application code that interacts with the HTTP session must use the following operation sequence to modify an object in the session:

1. Get object from the session (HttpSession.getAttribute()).

2. Modify object by calling a method.

3. Set object back into the session (HttpSession.setAttribute()).

This sequence is in any case mandatory, if the in memory HTTP session is being clustered and session failover/load balancing is required.

So how does this class actually work? SessionSize.getSessionSize() internally calls javawebparts.core.JWPHelpers.serializableTest() (a Web Parts utility class) for each session attribute, which serializes the object into a byte array and returns the size of the session.


The overall operation within a web application is shown in the following sequence diagram(Figure 2):

Deployment


The listener can be deployed unchanged to Servlet containers which conform to the 2.3, 2.4 and 2.5 versions of the Servlet API.

This class requires the following jars in the WEB-INF/lib directory:

• javawebparts-session-1.1.jar

• javawebparts-core-1.1.jar

• log4j-1.2.14.jar (or any recent version)

Add the following lines (Figure 3) in web.xml to register this listener.

The following log4j configuration file (Figure 4) directs all session size logging to separate a CSV formatted file (session-size.log).

The session-size.log file (Figure 5) can be imported into Microsoft Excel, where it can be analyzed and displayed. Here is a small section of the log generated by this listener.


The log contains the following information; the data/time, session id and session size in kilobytes.

Note that if the HTTP session contains a non-serializable object, the SessionSize.getSessionSize() method returns -1. This will result in the log file containing a size of -0.001 for the session!


For Example in an internet application development project which used Spring Webflow (http://www.springframework.org/webflow) as the MVC ‘Controller’ takes over all management of objects in the HTTP session, as well as storing its own state in the session, but we were unsure what impact this would have on the session size. We can use this listener to determine the size of the HTTP session for a single user.

Conclusion

There are many ways to use this data beyond simply determining the amount of memory used by your HTTP session. For example:

• Monitoring session size during a long running stress test (sometimes called a “soak” test) to check that it is stable (not increasing over time).

• Checking for objects that do not implement the java.io.Serializable interface. In this case the log file will contain a session size of -0.001. If session replication is enabled an exception will be throw by the servlet container if a non-serializable object is present in the HTTP session when it is replicated.

References

Java Web Parts - http://javawebparts.sourceforge.net/

Servlet Specification - http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html

Spring Webflow - http://www.springframework.org/webflow

Summary

This KB describes a simple method of monitoring the size of the Java HTTP session in any web application. This method can be used to monitor the HTTP session size during development and testing. When the application goes into production the memory used will be within the limitations imposed by the number of concurrent clients, hardware and other software running on the server.