JSESSIONIDs and Buddy Replication

[manik]

I'm starting this thread based on an email conversation that has been going on about this.

Based on buddy replication designs for JBossCache 1.4.0 and the design discussion thread for this design.
- http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheBuddyReplicationDesign
- http://www.jboss.com/index.html?module=bb&op=viewtopic&t=78308


In a nutshell, when mod_jk uses sticky sessions, it attaches a JVM ID to the end of the session - and this is stripped off before the JSESSIONID is placed in the cache. (Brian/Ben - am I correct here?)

After a node crash, when another node takes ownership of this session (basically mod_jk defaults to a load balancing algo and redirects the request to the next available node. This node then takes ownership of this session by locating it in the cluster - see BR designs) how would mod_jk know to change the JVM ID of this session to the NEW node?

Is this something:

1. That is standard across load balancers?
2. Something the clustering code base can manipulate?

[brian.stansberry]

In the case of mod_jk, this is already handled by the session replication layer. If useJK is "true" we add a valve (org.jboss.web.tomcat.tc5.session.JvmRouteValve) that analyzes requests, checking if the jvmRoute of the request's session doesn't match that of our Tomcat Engine. If there is a mismatch, we change the session id and emit a modified session cookie.

We need to look into making this functionality pluggable so we can add implementations interoperate with loadbalancers that use some other mechanism for identifying the sticky node.

See http://jira.jboss.com/jira/browse/JBCLUSTER-101.