You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@tomcat.apache.org by Scott Carlson <sc...@gmail.com> on 2012/10/25 20:06:08 UTC

Tomcat 7.0.30 CMA, clustering, and SSO

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.

Re: Tomcat 7.0.30 CMA, clustering, and SSO

Posted by Josh Gooding <jo...@gmail.com>.

Haha, Scott you're here too?

On Thu, Oct 25, 2012 at 2:06 PM, Scott Carlson <sc...@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.
>