Haha, Scott you're here too? On Thu, Oct 25, 2012 at 2:06 PM, Scott Carlson <scott.a.carl...@gmail.com>wrote:
> We've setup TC 7.0.32 with Clustering and Tomcat Container Managed > Authentication. HTTPSessions and SSOSessions are clustered across the > wire. With logging turned way up, I can see the synchronization and I can > see the sessions in the Tomcat Manager. > > When I "kill -9" one of the tomcats, I'm automatically swapped to the other > leg, and I'm still logged in. So it "works", unless I do a catalina.sh > shutdown. In that case, the SSO session is expired from the other leg. > The HTTPSession is still there, but because the SSO session is expired, > I'm forced to login again. This doesn't seem correct. The DeltaSession > looks at the notifyCluster parameter before sending a message to expire the > HTTPSession, but the ClusterSingleSignOn valve has already sent its message > to expire the SSO session by then. So the SSO is missing for the session. > > When shutting down, the stack trace looks like this (with some relevant > parameters replaced in line) isExpireSessionsOnShutdown() == false > ClusterSingleSignOn.deregister(SSOID) line: 274 > ClusterSingleSignOn(SingleSignOn).sessionEvent(SessionEvent) line: 247 > > DeltaSession(StandardSession).fireSessionEvent(Session.SESSION_DESTROYED_EVENT, > null) line: 1752 > DeltaSession(StandardSession).expire(true) line: 844 > DeltaSession.expire(true, false) line: 462 > DeltaManager.stopInternal() line: 967 > DeltaManager(LifecycleBase).stop() line: 232 > StandardContext.stopInternal() line: 5474 > StandardContext(LifecycleBase).stop() line: 232 > > > When doing a normal session invalidation (for logout), it ends up doing the > same thing, which is correct. > ClusterSingleSignOn.deregister(SSOID) line: 276 > ClusterSingleSignOn(SingleSignOn).sessionEvent(SessionEvent) line: 247 > > > DeltaSession(StandardSession).fireSessionEvent(Session.SESSION_DESTROYED_EVENT, > null) line: 1752 > DeltaSession(StandardSession).expire(true) line: 844 > DeltaSession.expire(true, true) line: 462 > DeltaSession.expire(true) line: 444 > DeltaSession(StandardSession).expire() line: 742 > DeltaSession(StandardSession).invalidate() line: 1253 > StandardSessionFacade.invalidate() line: 190 > > So I can't just change the DeltaSession to ignore that event. I can't just > have expire not call the super, or the HTTPSessionListeners would not be > called. > > I think this is a bug, but I don't see even a good fix for it. Ideas? If > this does look like a bug, I can log an issue for it. > > > Relevant server.xml here: > <Host name="localhost" appBase="webapps" unpackWARs="true" > autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false"> > <Valve > className="org.apache.catalina.ha.authenticator.ClusterSingleSignOn" /> > <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" > channelSendOptions="8"> > <Manager className="org.apache.catalina.ha.session.DeltaManager" > /> > <Channel > className="org.apache.catalina.tribes.group.GroupChannel"> > .... > </Channel> > <Valve className="org.apache.catalina.ha.tcp.ReplicationValve" > filter="" statistics="true" /> > <Valve > className="org.apache.catalina.ha.session.JvmRouteBinderValve" /> > <ClusterListener > className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener" > /> > <ClusterListener > className="org.apache.catalina.ha.session.ClusterSessionListener" /> > </Cluster> > </Host> > > The context XML just has a JDBCRealm realm configuration. >
