Using XStream to Troubleshoot Sessions

Monday, February 12, 2007

XStream is a great library that serializes and deserializes objects to and from XML, here we use it to troubleshoot a problem with HTTP sessions.

Finding and detecting problems with session state is one of the more difficult troubleshooting tasks. It tends to be difficult because objects in the session often have complex graphs with many nested objects. Factor in replication and things can get nasty quite quickly.

Last year I was helping a client troubleshoot a session problem where it appeared that certain attributes in the session were not being persisted after changes. The client was coming from a Websphere background where the session state can optionally be serialized after every request automatically. They had already corrected the obvious deficiency and ensured that setAttribute was called after each change to an object in the session.

Since I was unfamiliar with the application I needed a way to dump the session in a way that was human readable. While reflection is one option it turned that the work had been done for me already. XStream is an open source toolkit that enables any object graph to be serialized and deserialized to and from XML. With XStream viewing the session in a human readable format, XML, is child's play and makes it easy to see exactly what is in the session.

Thus the problem became immediately obvious when using XStream to dump the session. What we found was that the same object instance was being stored in the session using multiple attributes. On a single machine this was not an issue since a change to the object through any attribute affected all attributes as the object was a single instance. Replication throws a spanner in the works though.

As you probably know, WebLogic replicates only the attributes that have changed which means that WebLogic serializes and deserializes each object individually unlike Websphere which has an inefficient option to serialize and deserialize the entire session after each request.

This means that under Websphere the object would maintain its singleton nature since the whole session graph is serialized and deserialized in one go. Under WebLogic when the objects against each attribute are serialized and deserialized individually they become separate object instances. Changes to an object against one attribute are no longer reflected when the object is accessed through a different attribute.

What the client was experiencing was that occasionally a request would blip causing a failover to the secondary server. Once on the secondary server instead of dealing with a single object instance in the session they were now dealing with multiple copies of the same object all being in a different state. Updates to one object would not be reflected in others thus making them think that the session was not being persisted.

In short, XStream was invaluable for detecting this problem, being able to view the session in a human readable format saved me a ton of time and I’d recommend it to others dealing with issues that require being able to follow a complex object graph.

Posted by Gerald Nunn at 4:02 PM | Categories: WebLogic | | | Permalink