Currently, tomcat only generates a new sessionid if it's not NULL and tries to reuse the existing one. However, in the case of tomcat configured with load balancer using jvmRoute and user switch between clusters on the same browser session, tomcat see jsession cookie(with old jvmroute value from another cluster) and reuse it and it's not correct. The fix is to check jvmRoute value and it's note the same, generate new sessionId.
Created attachment 23959 [details] BaseManager.java with a fix
The patch is in the wrong format (full file rather than diff -u) and breaks the Manager API as described in the Javadocs. Without a justification of the "it's not correct" statement, I can't anything that is wrong with the current behaviour from a spec or functional point of view.
We are having the same problem. We have 4 JBoss 4.2.3 servers in a cluster using sticky session but no session replication. Here is the scenario. If the first request gets routed to node1, the sessionid will end in ".node1" and all requests will go back to that node. Let's say node1 goes down and the next request gets sent to node2. Since the session is not on node2, a new session is created. The problem is that the same session id, the one ending in ".node1" is reused instead of a whole new session id ending in ".node2" being created. There are 2 problems with this: 1) There are still 3 other JBoss servers running. All requests from the same browser using a session id ending in ".node1" will go to random JBoss servers (no more sticky sessions). This pretty much renders the app useless. 2) When node1 comes back up, the user again is switched back to node1 and remains there as sticky sessions kicks in.
For this to happen as described, a cookie intended for one cluster must be transmitted to a different cluster. This shouldn't happen. Given that the cookie will be selected by host and path, I don't see how this can happen. This looks like misconfiguration at this stage. I suggest you follow this up on the users list in the first instance. If that discussion concludes that there is a bug here, please re-open this issue and describe the steps to reproduce the bug. Note also that are are free to add custom valves and/or filters to manipulate the session cookie (or anything else) if necessary.