Bug 1523870 - [GSS](6.4.z) Clustered session still unexpectedly expired by sso after cluster member is stopped
Summary: [GSS](6.4.z) Clustered session still unexpectedly expired by sso after cluste...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web
Version: 6.4.18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: CR2
: EAP 6.4.19
Assignee: Brad Maxwell
QA Contact: Michael Cada
URL:
Whiteboard:
Depends On: 1441808
Blocks: eap6419-payload 1528686
TreeView+ depends on / blocked
 
Reported: 2017-12-08 22:05 UTC by Aaron Ogburn
Modified: 2018-04-16 11:06 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-16 11:06:08 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
bz1441808reproducer.zip (25.85 KB, application/zip)
2017-12-08 22:09 UTC, Aaron Ogburn
no flags Details

Description Aaron Ogburn 2017-12-08 22:05:21 UTC
Description of problem:

bz-1441808 did not fully address this.  When a single cluster member is stopped, sessions in its manager are cleared and other cluster members are notified that the sso entry for those sessions is now empty, so these members move that entry to their emptySSOs:

11-04-2017 05:02:02,316 TRACE [org.jboss.as.clustering.web.sso.infinispan.SSOClusterManager] (OOB-17,shared=tcp) received a session modified message for SSO p0vsaBCR6yVjvIOwEKHfzWRR
11-04-2017 05:02:02,316 TRACE [org.jboss.as.web.sso] (OOB-17,shared=tcp) Notified that SSO p0vsaBCR6yVjvIOwEKHfzWRR is empty

Despite continued activity for that session/sso on the remaining cluster members, the sso and its sessions are expired after the maxEmptyLife passes from when that cluster member was shutdown:

11-04-2017 06:46:12,376 TRACE [org.jboss.as.web.sso] (ajp-/0.0.0.0:11409-382) Associate sso id p0vsaBCR6yVjvIOwEKHfzWRR with session SessionBasedClusteredSession[id: ylja2xlbE9XnFsbP8OsLTH-k lastAccessedTime: 1491885960368 version: 8181 lastOutdated: 0]
11-04-2017 06:46:21,488 TRACE [org.jboss.as.web.sso] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Invalidating expired SSO p0vsaBCR6yVjvIOwEKHfzWRR
11-04-2017 06:46:21,488 TRACE [org.jboss.as.web.sso] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Deregistering sso id 'p0vsaBCR6yVjvIOwEKHfzWRR'
11-04-2017 06:46:21,496 TRACE [org.jboss.as.clustering.web.sso.infinispan.SSOClusterManager] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Registering logout of SSO p0vsaBCR6yVjvIOwEKHfzWRR in clustered cache
11-04-2017 06:46:21,498 TRACE [org.jboss.as.clustering.web.sso.infinispan.SSOClusterManager] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) cacheEntryRemoved ssoId = p0vsaBCR6yVjvIOwEKHfzWRR
11-04-2017 06:46:21,498 TRACE [org.jboss.as.web.sso] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Notified that SSO p0vsaBCR6yVjvIOwEKHfzWRR is empty
11-04-2017 06:46:21,498 TRACE [org.jboss.as.clustering.web.sso.infinispan.SSOClusterManager] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Registering logout of SSO p0vsaBCR6yVjvIOwEKHfzWRR in clustered cache
11-04-2017 06:46:21,488 TRACE [org.jboss.as.web.sso] (ContainerBackgroundProcessor[StandardEngine[jboss.web]])  Invalidating session SessionBasedClusteredSession[id: ylja2xlbE9XnFsbP8OsLTH-k lastAccessedTime: 1491885960368 version: 8182 lastOutdated: 0]


Version-Release number of selected component (if applicable):


How reproducible:

Always


Steps to Reproduce:
1. Launch two nodes with the attached configuration and the SimpleWar.war deployed.  It helps reproduce more quickly with a shorter maxEmptyLife/processExpiresInterval:

./standalone.sh -c standalone-sso.xml -Dorg.jboss.as.web.sso.ClusteredSingleSignOn.maxEmptyLife=60 -Dorg.jboss.as.web.sso.ClusteredSingleSignOn.processExpiresInterval=1 -Djboss.node.name=node1

./standalone.sh -c standalone-sso.xml -Dorg.jboss.as.web.sso.ClusteredSingleSignOn.maxEmptyLife=60 -Dorg.jboss.as.web.sso.ClusteredSingleSignOn.processExpiresInterval=1 -Djboss.socket.binding.port-offset=100 -Djboss.node.name=node2

2. Access localhost:8080/SimpleWar/secure/hi.jsp and login (admin/redhat1!).  Note the sessionid/sso generated.
3. Access localhost:8180/SimpleWar/secure/hi.jsp
3. Stop node1
4. Wait one minute for maxEmptyLife to pass.  
5. In a new browser session, access localhost:8180/SimpleWar/secure/hi.jsp and login then access localhost:8180/SimpleWar/secure/invalidate.jsp in this same session (this is to trigger expiration tasks)
6. Note that the sessionid/sso from step 2 are expired

Actual results:

Clustered SSO entry becomes an "emptySSO" after a cluster member stops.  This leads to unexpected SSO/session expiration after maxEmptyLife passes.


Expected results:


Clustered SSO entry does not become an "emptySSO" after a cluster member stops and/or continued activity on other cluster members removes it from emptySSO.


Additional info:

To address this, perhaps ClusteredSingleSignOn.sessionEvent should not broadcast that the SSO is empty when the session is expired because the manager is stopping.

And/Or perhaps ClusteredSingleSignOn.associate should ensure the sso is removed from emptySSOs.  With bz-1441808, it is only removed from emptySSOs if sso.addSession2 returned true.  That generally only happens on the first associate call.  So if a cluster member stops after the first associate, then subsequent associate calls no longer remove it from emptySSOs as needed.

Comment 1 Aaron Ogburn 2017-12-08 22:09:54 UTC
Created attachment 1365047 [details]
bz1441808reproducer.zip

Comment 6 Jiří Bílek 2018-01-16 12:35:15 UTC
Verified with EAP 6.4.19.CP.CR2


Note You need to log in before you can comment on or make changes to this bug.