Session Replication on Cloud Foundry

August 21, 2014 Christopher Frost

featured-polycloud-greenRecently, 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.

$> cf restage cfrost-session-application
-----> Java Buildpack Version: 41ccef3 |
-----> Downloading Open Jdk JRE 1.7.0_65 from (found in cache)
Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (1.0s)
-----> Downloading Spring Auto Reconfiguration 1.4.0_RELEASE from (found in cache)
-----> Downloading Tomcat Instance 7.0.54 from (found in cache)
Expanding Tomcat to .java-buildpack/tomcat (0.1s)
-----> Downloading Tomcat Lifecycle Support 2.2.0_RELEASE from (found in cache)
-----> Downloading Tomcat Logging Support 2.2.0_RELEASE from (found in cache)
-----> Downloading Tomcat Access Logging Support 2.2.0_RELEASE from (found in cache)
-----> Downloading Tomcat Redis Store 1.2.0_RELEASE from (0.0s)
Adding Redis-based Session Replication
-----> Uploading droplet (45M)
1 of 1 instances running
App started

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.

$> redis-cli keys *
1) "A174CD1FC86066A01B78572DED1F9618"
2) "D6B37E35788FCC50CD5B28FB68682735"
3) "78CBE316C140C3528D0B6590A7CAC774"
5) "F189383702E2694552277EB1ACC3F1A5"
6) "B8A7D7A229B063BB9E4A5F853BB95D9D"
7) "25EF288A4552F24735CDCC78D169F776"

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.

About the Author


More Content by Christopher Frost
Using Docker For CI Pipelines
Using Docker For CI Pipelines

A previous post explained CI pipelines for loggregator, and this post zooms in on why the Cloud Foundry eng...

Experience NO LIMITS: Join Pivotal at VMware VMworld US 2014
Experience NO LIMITS: Join Pivotal at VMware VMworld US 2014

This weekend Pivotal will join forces with VMware and our collective customers at VMworld 2014. Pivotal wi...

Enter curious. Exit smarter.

Register Now