Sticky Sessions and Session Replication

up vote2down votefavorite 3

I am evaluating the case of using sticky sessions with Session replication in tomcat. From my initial evaluation, I thought that if we enable Session replication, then session started in one tomcat node will be copied to all other tomcat nodes and thus we do not need sticky session to continue sessions and the request can be picked up by any node. But it seems that session replication is in general used with sticky sessions, otherwise the session id needs to be changed whenever the request goes to some other node. ref:http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html#Bind_session_after_crash_to_failover_node Can anyone explain what is the real use of session replication if you have to enable sticky session? Because then you would be unnecessarily copying the session on each node, when the request with a given session id is always going to the same node. It could be beneficial in case of a node crashing, but then that does not happen frequently and using session replication only for that seems like an overkill. session tomcat session-replication share|improve this question asked Jun 16 '11 at 6:14 Ashish 60411023

Not the answer to what you asked, but perhaps still be useful: you might check out memcached-session-manager (code.google.com/p/memcached-session-manager), which provides session replication also for non-sticky sessions. –  MartinGrotzke Jun 16 '11 at 12:05 add comment

3 Answers

activeoldestvotes

up vote3down voteaccepted

I think the only real benefit is to be able to shut down Tomcat instances without much thinking. Especially this applies today in cloud world (think Amazon AWS spot instances) when nodes can go on and off really often. Alternative to this would be to buy a decent load balancer which supports node draining. But decent load balancers are expensive, and draining takes time. Another scenario I can think of is a (poor implementation of) shopping cart where items are kept in theHttpSession and shutting down would require the user to re-purchase them (which would likely lead to a lost sale). But in most cases you're right - benefit of having both sticky sessions and session replication is very negligible. share|improve this answer answered Jun 17 '11 at 22:04 mindas 11.7k52781

Thanks for your response. Thanks seems fine, but still I am not sure if session replication needs to be enabled with sticky sessions or can it be used without sticky sessions too? –  Ashish Jun 20 '11 at 14:52 Replication can be used without sticky sessions and vice versa. –  mindas Jun 20 '11 at 14:54 But as mentioned in this link... tomcat.apache.org/tomcat-6.0-doc/… ... it seems that enabling session replication without sticky session seems to cause problems –  Ashish Jun 20 '11 at 15:01  1   I don't see where the article says this causes problems. Article speaks about mod_jk which is irrelevant in this context. –  mindas Jun 20 '11 at 15:29 add comment

up vote9down vote

As Mindas explained it before : When you use loadbalancing it means you have several instances of tomcat and you need to divide loads. If you're using session replication without sticky session : Imagine you have only one user using your web app, and you have 3 tomcat instances. This user sends several requests to your app, then the loadbalancer will send some of these requests to the first tomcat instance, and send some other of these requests to the secondth instance, and other to the third. If you're using sticky session without replication : Imagine you have only one user using your web app, and you have 3 tomcat instances. This user sends several requests to your app, then the loadbalancer will send the first user request to one of the three tomcat instances, and all the other requests that are sent by this user during his session will be sent to the same tomcat instance. During these requests, if you shutdown or restart this tomcat instance (tomcat instance which is used) the loadbalancer sends the remaining requests to one other tomcat instance that is still running, BUT as you don't use session replication, the instance tomcat which receives the remaining requests doesn't have a copy of the user session then for this tomcat the user begin a session : the user loose his session and is disconnected from the web app although the web app is still running. If you're using sticky session WITH session replication : Imagine you have only one user using your web app, and you have 3 tomcat instances. This user sends several requests to your app, then the loadbalancer will send the first user request to one of the three tomcat instances, and all the other requests that are sent by this user during his session will be sent to the same tomcat instance. During these requests, if you shutdown or restart this tomcat instance (tomcat instance which is used) the loadbalancer sends the remaining requests to one other tomcat instance that is still running, as you use session replication, the instance tomcat which receives the remaining requests has a copy of the user session then the user keeps on his session : the user continue to browse your web app without being disconnected, the shutdown of the tomcat instance doesn't impact the user navigation. share|improve this answer answered Jun 15 '12 at 6:09 Nico 162210

This is well understood, my question was only if it has any other use apart from node crash, as I mentioned in the question itself "It could be beneficial in case of a node crashing". –  Ashish Jul 8 at 13:53 ok, you talk about "node crashing" but you could also want to change two nodes, or remove two nodes, or you want to update your web application... and in doing this you don't want to stop the session of users, you want them not to see your intervention. Then using replication will permit you to do this. –  Nico Sep 19 at 7:27 add comment

up vote0down vote

Just to clarify configuration issues on JBoss 5.X in "all" base configuration with mod_jk. Setting sticky sessions in workers.properties file worker.list=loadbalancer ... nodes configuration omitted worker.loadbalancer.balance_workers=node1,node2 worker.loadbalancer.sticky_session=True does not prevent session replication. In order to switch off session replication on JBoss we need to set in $JBOSS_HOME\server\YOUR_NODE_NAME\deploy\cluster\jboss-cache-manager.sar\META-INF\jboss-cache-manager-jboss-beans.xml cacheMode parameter to LOCAL. Usually in sticky session scenario we don't want session replication, since we do not want additional overhead connected with significant amount of I/O operations needed to replicate sessions. In fact, if go with sticky sessions, we do not need to run JBoss in "all" configuration, we might use "default" or "standard" based configuration. The only thing that has to be done is change in $JBOSS_HOME/server/YOUR_NODE_NAME/deploy/jbossweb.sar/server.xml: share|improve this answer answered Mar 30 '12 at 19:18 Piotr Kochański 7,13423039

add comment