la réplication de session Can a lieu sans séance collante?

Question

Dans le contexte de Tomcat, la réplication de session peut se déroule sans activer la session collante?

Je comprends le but de la séance est collante pour que le client « bâtons » à 1 serveur tout au long de la session. Avec la réplication de session, l'interaction du client avec le serveur est répliqué dans tous les clusters (de nombreux serveurs Web).

Dans le cas ci-dessus, la réplication de session peut se déroule? session de savoir client est bien les propagation des serveurs Web et chaque interaction avec l'un des serveurs Web est répliqué à travers, donc, ce qui permet l'interaction transparente.

Answer 1

AFAIK, tomcat clustering does not support non-sticky sessions. From tomcat docs:

Make sure that your loadbalancer is configured for sticky session mode.

But there's a solution (I created, so you know I'm biased :-)) called memcached-session-manager (msm), that also supports non-sticky sessions. msm uses memcached (or any backend speaking the memcached protocol) as backend for session backup/storage.

In non-sticky mode sessions are only stored in memcached and no longer in tomcat, as with non-sticky sessions the session-store must be external (to avoid stale data).

It also supports session locking: with non-sticky sessions multiple, parallel requests may hit different tomcats and could modify the session in parallel, so that some of the session changes might get overwritten by others. Session locking allows synchronization of parallel requests going to different tomcats.

The msm home page mainly describes the sticky session approach (as it started with this only), for details regarding non-sticky sessions you might search or ask on the mailing list.

Details and examples regarding the configuration can be found in the msm wiki (SetupAndConfiguration).

Just to give you an idea regarding the complexity: what you need is one or more memcached servers running (or s.th. similar speaking memcached) and an updated tomcat context.xml like this:

<Context>
  ...
  <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
    memcachedNodes="n1:host1.domain.com:11211,n2:host2.domain.com:11211"
    sticky="false"
    sessionBackupAsync="false"
    lockingMode="auto"
    requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
    />
</Context>

Your load-balancer does not need special configuration, so once you have these things in place you can start testing your application.

Answer 2

An excellent article about this topic here:

• http://www.mulesoft.com/tomcat-cluster

The terracotta product they mention has a simplistic tutorial here:

• http://www.terracotta.org/documentation/web-sessions/get-started

Terracotta works on Tomcat but you must pay attention to check which bits of Terracotta are free and which are commercial. A couple of years ago their redundant store was paid and I don't remember this solution being a separated product.

Answer 3

I have actually found the inverse to this question. Session replication for me (Tomcat7) with the OOTB options only works properly WITHOUT Sticky Session. After turning the logging up I found that with the JVMRoutes enabled my session ID goes from A123456789 to A123456789.01 -- suffixed with the jvmroute. That session is successfully replicated from Node 01 in the cluster to Node 02 but uses the same ID (A123456789.01). When I take Node 01 out of the cluster then the traffic starts to stick on Node 02 -- and it looks now for a session A123456789.02 which of course does not exist. .01 is there, but basically sits idle until it expires. If I bring the other server up and the sessions are replicated and then take 02 down, I get even odder behaviour because the session is picked up where it left off.

For me, so far, session replication without sticky sessions (just regular RR amongst the nodes in the cluster) is the only thing that has worked.