Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.

Spring MVC and XRebel: Uncovering HttpSession Issues with the profiler for Java development

Building web applications with Spring MVC often requires to store some user data – some examples are security credentials, profile information, temporary conversational objects and others. The natural way to do that in Spring MVC is by setting the HttpSession attributes either directly or through the session scope descriptors.

In the Spring MVC Petclinic sample application session scope is used througout. For example, in the OwnerController:

@SessionAttributes(types = Owner.class)
public class OwnerController {
    @RequestMapping(value = "/owners/new", method = RequestMethod.GET)
    public String initCreationForm(Map<String, Object> model) {
        Owner owner = new Owner();
        model.put("owner", owner);
        return "owners/createOrUpdateOwnerForm";

A common issue in Spring MVC applications is that session attributes are set and never cleared up. Looking into which attributes are set and how big they are is challenging. A usual approach is to do a heap dump and then use a tool like the Eclipse Memory Analyzer to parse the heap and find the session storage. However it is much easier to monitor the session with an interactive profiler, like XRebel.

XRebel is an always-on, interactive profiler that runs in the background and notifies the user when and if an issue is detected. In case of user session, XRebel displays the running session size and difference from previous request on the toolbar alongside the application as you click around.


If we fill out the New Owner form, press “Add Owner” and then click on the Session component on the XRebel toolbar we shall see the following view:


As you can see not only are the attributes and their sizes immediately visible, but we can also drill down into their individual subcomponents as well as see what has been added on the last request through the “Diff” column.

XRebel can also detect when the session gets too large and issues an alert. By clicking on “Add Visit” on the Edit Owner page, we get the following view:


As you can see XRebel warns us that the session grew too large too quickly. Clicking on the session component provides the following view:


Clearly visitController should not be in the user session. Searching on google for the first attribute also uncovers that it’s associated with the Controller. Looking at the VisitController code reveals the following common issue:

public class VisitController {

The annotation @Scope("session") forces the Controller to be session-scoped, by creating an associated HttpSession attribute. Deleting that annotation solves the problem. If we’re using JRebel in conjunction with XRebel, we can quickly fix the code and reverify with XRebel that the session is a more reasonable size.

HttpSession issues can be painful and cumbersome to detect as noted by Jens Löfgren from Folksam on our forum:

We’ve had some real OutOfMemory problems in our production environment for quite some time. Once I got XRebel up and running I noticed that our most used webapplication uses around 15MB/Usersession. Quite a lot… We’re using Spring Webflow + JSF2 (Mojarra) and thanks to XRebel I noticed that by tuning a few JSF parameters I got the average user session from 15MB to 0,5MB.

Interactive profilers like XRebel are great at uncovering such issues before they go to production and cause OutOfMemoryErrors or Garbage Collection issues that affect your end users.