Poor session Id implementation in Weblogic (and potentially websphere) may cause memory leaks to objects keyed off of HttpSession.getId()

• Type: Bug
• Status: Closed
• Resolution: Fixed
• Affects Version/s: 5.2.9 EE, 6.0.11 EE, 6.1.0 CE RC1
• Fix Version/s: 6.0.12 EE, 6.1.0 CE RC1
• Component/s: Environments, Environments > App Servers
• Labels:
  • LPE-F
• Branch Version/s:
  6.0.x
• Backported to Branch:
  Committed

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

This may lead to objects being cached according to the sessionId to become stranded and thus a memory leak.