In a WebLogic cluster, the HttpSession.getId() call returns a string that not only includes the session ID but also what WebLogic refers to as JVMIDs. These values indicate which nodes in the cluster are the active and which one is preferred. For example, getId() might return a value that looks like this:

xdp5KfxT0VhR8WJJFcphQZCTQ1GdlH6T5g392NVlpdZm1qvdTVPT!-2015310958!-1301377968!1256157555082

The entire string is made up of the actual session id PLUS a couple of unique identifiers (delimited by '!') for cluster nodes (the final value is something else). The JVMIDs are used by the WebLogic plugin (at least) for routing requests. If you shut a cluster node down, the getId() call will return something like this - the node that is down is now indicated as 'NONE':

xdp5KfxT0VhR8WJJFcphQZCTQ1GdlH6T5g392NVlpdZm1qvdTVPT!-1301377968!NONE!1256157555082

Starting the node back up shows that a new JVMID is used to indicate the recently restarted node:

xdp5KfxT0VhR8WJJFcphQZCTQ1GdlH6T5g392NVlpdZm1qvdTVPT!-1301377968!1294882958!1256157555082

Our SessionDispatcher relies on the session ID as a key to store information in a couple of different collections. The result is that, when the session ID mutates as nodes go up and down, the values that are mapped to the session ID keys can get orphaned. The SessionDispatcher will simply add a new entry to the map, keyed on the the new sessionID. So far I haven't seen and detrimental behaviour (the proper session always appear to be used) but the orphaned values in the map may never be properly garbage collected even when the session expires because the same session ID may never be provided by the container.

My question is, is this mutating session ID going to cause problems for anything in the core (like the Session Dispatcher) or the EPS?