Session Replication on Cloud Foundry

Recently, the Java Buildpack added support for session replication using Redis. This support complements the existing session affinity (i.e. sticky sessions) that Cloud Foundry already supports. So now, in addition to having sessions routed to the instance they were created on, sessions will also survive the loss of that instance. The Java Buildpack will auto-configure Redis-based Session Replication for you when it notices that you’ve bound to a specially identified Redis service.

By default, the Tomcat instance provided by the Java Buildpack is configured to store all sessions and their data in memory. To make the instance use Redis-based Session Replication instead, bind a Redis service containing a name, label, or tag that has session-replication as a substring and the Java Buildpack will do the rest. restageing your application will cause the required dependencies to be downloaded and configured.

The console output shows that the Tomcat Redis Store is downloaded because your application is bound to a Redis service. Redis-based Session Replication is then added to the Tomcat instance because of the service’s name. You can verify the session persistence directly by exercising your application from a couple of different browsers and then using the redis-cli tool to inspect Redis.

The Redis keys are the ids of the stored sessions. These sessions can be retrieved by any instance of your application. This means that if an instance of your application crashes or is restarted, any other live instance can pick up the session and the user won’t have to start again. You can try this for yourself with this demo application and a full walk-through in Ben Hale’s CF Summit 2014 talk at 9 minutes in.