-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Imagine you have a web application with sticky sessions running on several tomcats 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 handled by sessions that are stored for backup in memcached nodes: If a tomcat dies all other tomcats will take over the work of the lazy/dead one and fetch the sessions from the appropriate memcached node(s) and serve this session from thereon.
The memcached session manager installed in a tomcat holds all sessions locally in the own jvm, just like the StandardManager does it as well.
Additionally, after a request was finished, the session (only if existing) is additionally sent to a memcached node for backup.
When the next request for this session has to be served, the session is locally available and can be used, after this second request is finished the session is updated in the memcached node.
Now imagine the tomcat dies.
The next request will be routed to another tomcat. This tomcat (in more detail the memcached session manager) is asked for a session he does not know. He will now lookup the session in the memcached node (based on an id that was appended to the sessionId when the session was created). He will fetch the session from memcached and store the session locally in its own jvm – he is responsible for that session from now on. After the tomcat served this request of course he also updates the session in the memcached node.
That’s all.
Also memcached node failover is implemented: if a memcached node is not available anymore the session will be moved to anoder node – also the sessionId will be modified and a new JSESSIONID cookie will be sent to the browser. As you are using sticky sessions make sure that the loadbalancer does use only the “plain” sessionId, without the suffix.
The memcached session manager knows a list of memcached nodes (e.g. as n1:localhost:11211 n2:localhost:11212 that he references by the specified id (n1/n2). This id is encoded in the sessionId, so the sessionId might be 602F7397FBE4D9932E59A9D0E52FE178-n1.
- Update list of memcached nodes via JMX
- Automated integration testing of all this (start memcached servers, start tomcats, make requests + create sessions, simulate tomcat failure etc.)