Persisting Tomcat Sessions to Redis

This is the story of how we achieved high availability and session persistence in our Tomcat clusters. Years ago, before the Cloud was born, SysAid was founded. During those dark times software ran on bare metal, there were no microservices and AWS was just a twinkle in Andy Jassy’s eye. Things were a lot different then. Software was written in a completely different environment, with different constraints. But today it’s different. A LOT different. As such, I’ve decided to embark on a new blog series writing about the modernization of SysAid’s technology and our migration from a mostly monolithic architecture to microservices in the cloud. You can expect one-two blogs a month and I’ll be writing on a number of topics, including cost and performance optimization, handling legacy code, migrating to the cloud and hunting bugs in production. Today I’m starting with persisting Tomcat sessions to Redis.

Want to achieve high availability and session persistence in your Tomcat clusters? Check out this @SysAid blog. #servicedesk Share on X

The problem

Say you have a web application and everything is going smoothly. Users are logging in, clicking buttons, filling in forms and everyone’s happy. Then one day disaster strikes and your application server crashes. Now everyone is less happy. You scramble to bring up another application server and in a few seconds it’s up and running. Whew! All is well. Wait, not really. Your users have lost their session data. Everything not saved to the database is gone. Depending on how your application is written the effect can range from inconvenient and embarrassing to disastrous.

Something needs to change. So you get a pencil and paper and you get architecting. If you want to recover more elegantly from the next crash here are the requirements:

1. You need a fallback application server to be up at all times, take the place of the one that crashed and make sure your users are not twiddling their thumbs or wishing you unpleasant deaths as they wait for the backup server to come back up.
2. You need to store the session information outside the Tomcat so it’s not lost.

The solution? A cluster of application servers and some sort of reliable storage medium for the session information.

The solution

Now you get down to specifics. Your application servers are Tomcats. You bring up two of those, that’s no problem. Can Tomcat persist its session externally? Yes it can! Tomcat has an interface org.apache.catalina.Manager whose implementations manage sessions. Out of the box it uses StandardManager, but you can configure it to use a different one. There’s one that’s called PersistentManager which looks promising. Usually it persists sessions to disk but that’s not what we’re looking for here since we want the other Tomcat in the cluster to be able to access the session too. Hmmm…so what to do? Well, looking at the source it looks like PersistentManager uses an implementation of Store to store the sessions. Can you provide your own implementation? Easily! Now where should you save your session to? We need quick access and we don’t need sophisticated querying capabilities. So some sort of fast key-value store. Redis, obviously.

The Tomcat Store interface is very simple to implement. All you need now is a Redis library in Java. Jedis (the Java library, not the order of galactic knights) seems simple enough. Anything else? Well, you might want to monitor what the session manager is doing so you need metrics too. Dropwizard should do nicely. Now let’s get coding.

The API for Store is fairly simple.

• Load a session using load(String sessionId).
• Delete a session using remove(String sessionId).
• Persist a session with save(Session session).
• Delete all sessions using clear().
• Get all session IDs with keys().
• Get the number of sessions with getSize().

Want to recover more elegantly from your next application server crash? Here's how. #servicedesk Share on X

And here’s the result:

Put that into a jar. To use it just drop it in Tomcat’s classpath and add the following to context.xml:

Does all this sound interesting? Great! I’m hiring a software architect. If you want to talk here’s a link to the job description: https://www.sysaid.com/company/careers/positions/co/rd/F4.22A/software-architect/all