Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.8.2-EE-Beta
-
Fix Version/s: 1.8.2-EE-GA, 1.8.3
-
Component/s: Framework
-
Labels:None
-
Environment:WebLogic cluster
-
Affects:Documentation (User Guide, Ref. Guide, etc.)
Description
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?
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?
Issue Links
- blocks
-
IPCK-23
Mutating session ids in WebLogic cluster
-
- Closed
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Salesforce Case | [] | |
| Fix Version/s | 1.8.3 [ 10211 ] | |
| Assignee Priority | P2 | |
| Description |
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: 3) 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? |
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? |
| Salesforce Case | [] | |
| Fix Version/s | 1.8.2-EE-GA [ 10216 ] | |
| Affects Version/s | 1.8.2-EE-Beta [ 10215 ] | |
| Affects Version/s | 1.8.2 [ 10190 ] |
| Salesforce Case | [] | |
| Assignee Priority | P2 | P1 |
| Assignee | Jack Van Ooststroom [ jack.van.ooststroom ] |
| Repository | Revision | Date | User | Message |
| ICEsoft Public SVN Repository | #19833 | Tue Dec 01 03:54:46 MST 2009 | jack.van.ooststroom | Fixed JIRA |
| Files Changed | ||||
MODIFY
/icefaces/trunk/icefaces/core/src/com/icesoft/faces/webapp/http/servlet/MainServlet.java
MODIFY
/icefaces/trunk/icefaces/core/src/com/icesoft/faces/webapp/http/servlet/SessionDispatcher.java
MODIFY
/icefaces/trunk/icefaces/push-server/src/org/icefaces/push/server/PushServlet.java
|
| Salesforce Case | [] | |
| Affects | [Documentation (User Guide, Ref. Guide, etc.)] |
| Repository | Revision | Date | User | Message |
| ICEsoft Public SVN Repository | #19837 | Tue Dec 01 07:49:27 MST 2009 | jack.van.ooststroom | Fixed JIRA |
| Files Changed | ||||
|
MODIFY
/icefaces/trunk/icefaces/core/src/com/icesoft/faces/webapp/http/servlet/SessionDispatcher.java
|
| Salesforce Case | [] | |
| Security | Private [ 10001 ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
| Status | Resolved [ 5 ] | Closed [ 6 ] |
| Assignee Priority | P1 | |
| Assignee | Jack van Ooststroom [ jack.van.ooststroom ] |
The SessionDispatcher now has the ability to strip off any extra information from the JSESSIONID as this extra information especially in a WebLogic Server Cluster mutates as nodes are going down and starting up causing an eventual reload of the page. This seems to cause some issues with EPS in a WebLogic Server cluster eventually resulting into a Network Connection Interrupted message. As only the extra information of the JSESSIONID is mutating, the SessionDispatcher is now able to strip this off only when the com.icesoft.faces.sessionIdDelimiter context parameter is defined in the ICEfaces application's web.xml. If this context parameter is not defined the stripping off logic is not executed. Marking this one as FIXED.