Session Replication via Memcached

By | October 3, 2012
Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

If you didn’t know, Jelastic provides Session Replication between instances of web-servers with a the help of multicast. As we mentioned, this boils down to properly setting up session replication between Tomcat, GlassFish and Jetty web servers in Jelastic and configuring load balancer redirecting requests to them. You can also use Session Replication via Memcached.

tomcat memcachedThe main purpose of Memcached is to provide an easy to use distributed caching engine in a multinode environment. But, imagine that you have a web application with sticky sessions running on several app servers and want to have some kind of session failover. You want to have a scalable solution for that – just add more servers to handle an increasing number of sessions. This can be processed by sessions that are stored for backup in Memcached node: if a one server dies all the others will take over the work of the dead one and fetch the sessions from Memcached and serve this session from thereon.

The memcached session manager and Jelastic will help you to implement this. The memcached session manager installed in a server holds all sessions in its own jvm. Additionally, after a request was finished, the session is sent to a memcached node for backup. When the next request for this session has to be served, the session is available and can be used. After the second request is finished the session is updated in the memcached node. Now lets imagine the server dies. The next request will be routed to another one. This application server is asked for a session it does not know. It will now lookup the session in the memcached node (based on an id that was appended to the sessionId when the session was created). It will fetch the session from memcached and store the session in its own jvm: it is responsible for that session from now on. After the server answers this request it also updates the session in the memcached node. So the server’s failover is handled completely.

To use memcached for session replication follow the given instruction:

Create the environment

1. Go to and sign up if you haven’t done it yet or log in with your Jelastic credentials by clicking the Sign In link on the page.

2. Ask Jelastic to create a new environment.

memcached replication

3. In the Environment topology window choose two or more servers you want to use (for example, two instances of Tomcat 7) and Memcached node. Type the name of the environment (for example, memcachedreplication) and click Create.

memcached session

In a minute your environment will be created.

memcached session replication

Configure application server

1. Download .jar file of Memcached session manager. As the example we used memcached-session-manager-1.6.2. Also download memcached-session-manager-tc7-1.6.2.jar, spymemcached-2.8.4.jar, msm-kryo-serializer-1.6.1.jar, kryo-1.03.jar, reflectasm-0.9.jar, kryo-serializers.jar, joda-time.jar and minlog-1.2.jar.

2. Click Config for Tomcat.

session replication

3. In the opened window choose lib folder and upload the .jar files you’ve just downloaded.

replication between instances

4. Choose server folder and open context.xml file.

5. Update context.xml so that it contains the Manager configuration for the memcached-session-manager, like this:

<Context path="" docBase="ROOT">
 <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"

You can use any other serialization strategy according to your needs, in our case we use Kryo, an extremely fast binary serialization library.
memcached node

6. In the string memcachedNodes add your memcached host and default port(11211). In our case we have:

To get your memcached host click Info button for Memcached node in your environment.

memcached host

7. In the opened window you’ll find the host. Copy it and add to the memcachedNodes string.

memcached hosting

8. Save the changes and restart your server node (in our case Tomcat).

That’s all. Now your have a high available cluster with all the advantages of Memcached. Stay tuned for even more exiting stuff!

Related article:

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

Subscribe to get the latest updates

  • Pingback: Geek Reading October 4, 2012 | Regular Geek()

  • Nice post!
    Regarding the jars that should be copied everything starting from msm-kryo-serializer jar (msm-kryo-serializer, kryo, reflectasm, kryo-serializers and minlog) should not go into $CATALINA_HOME/lib but into WEB-INF/lib of the webapp. People using maven (or similar) can just declare a dependency on de.javakaffee.msm:msm-kryo-serializer:1.6.2:jar that pulls the other transitive jars in.

    Even shorter: just leave it out and go for plain old java serialization (instead of kryo, even if I’d recommend kryo over java serialization in terms of performance). Then only the msm core, msm-tc7 and spymemcached jars go into $CATALINA_HOME/lib and that’s it.
    The config in context.xml then looks like this:

    Regarding the customConverter JodaDateTimeRegistration it’s worth mentioning that this is of course only needed/useful if joda time is used by the application (so it could be left out here).

  • D’oh, wordpress ate the stuff after “The config in context.xml then looks like this:”, so once again now with square brackets (hopefully this won’t be removed silently by wp). Simplified config with plain old java serialization instead of kryo would look like this:

    [Manager className=”de.javakaffee.web.msm.MemcachedBackupSessionManager”
    sessionBackupAsync=”false” /]

    • Hello Martin!
      Thanks for good words. Sorry one more time for the delay with the moderation. And thanks for your comments, they are very useful for me and for our users.

  • Nice – but what is the Memcached node goes down and all your app sessions will be lost

  • magrokosmos

    In sticky session mode sessions still live in tomcat, so memcached only adds HA for tomcat failure.

    When memcached fails the session is still served by tomcat. When you’re running tomcat + memcached-session-manager with several memcached nodes, tomcat uses the next memcached node from the “ring” for session backup in the case of a memcached failure or when a memcached node is removed.

  • Pingback: Running a ContentBox Cluster on Jelastic Cloud PaaS()

  • Pingback: Running a ContentBox Cluster on Jelastic Cloud PaaS | Jelastic()