persisting HTTP sessions over restarts on JBoss 4.0.4

I spent another frustrating day delving into JBoss configuration this week, just to restore behaviour we want in our application.

What we want to happen is that HTTP session attributes are ‘magically’ persisted when the server is shutdown, and restored when the server starts again. This means we can minimise disruption on our live service when we deploy updates.

This behaviour was automatic previously when we were running on JBoss 3.2.x, but after upgrading to JBoss 4.0.4.GA, it stopped working. Looking around on the JBoss site I found that they have deliberately disabled this functionality by default – the several discussions and bug reports complaining about it suggested why!

I soon found that a context.xml file had been added under the jbossweb... deployment structure, specifying a Tomcat Manager and setting its pathname to empty. The Tomcat Configuration page explains the effect of this.

So I uncommented the replacement Manager offered by this JBoss version of context.xml and expected it to work… It took quite a while to investigate, but I eventually discovered that setting a simple name for the manager e.g.

<manager pathname="SESSIONS.ser">

did cause the sessions to be written out to that file, but unfortunately the file was written in a working directory that was deleted by the time the server finished shutting down!

I then tried setting the pathname to an absolute path, but this resulted in each web application trying to write to the same file, with the last one to do so ‘winning’.

So my final workaround was to add a context.xml to each individual web app – it goes in the WEB-INF directory – to set the Manager pathname to one including that web app’s name. I also used a relative path of ../../.. to make the session files be written outside of the working directories that would be deleted, but avoid using a non-portable path.

This seemed to do the trick. Phew! (As an aside, I haven’t actually written a context.xml for each web app – they are dynamically created by our build script).

Post a Comment

Your email is never published nor shared. Required fields are marked *