Bug 57532

StandardManager should be irrelevant since it isn't used for clustered web applications. The web application should be using DeltaManager.

On shutdown DeltaManager calls to two argument version of Session.expire() with the second argument set depending on expireSessionsOnShutdown.

I'd like to see a stack trace that shows where the call to DeltaSession.expire() is coming from.

Hey Mark,

I'll try to grab those details for you. All I can say for the moment is that if I set a breakpoint in the DeltaManager class for the expire(boolean) method, then during shutdown it hits. The only way I was able to preserve my session replication was to modify that method. Perhaps I have configured my cluster incorrectly? -- here is my configuration. I'll try to find some time this weekend to get a thread dump for you. 


server.xml --

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" channelSendOptions="6">
<Manager className="org.apache.catalina.ha.session.DeltaManager"
                  expireSessionsOnShutdown="false"
                  notifyListenersOnReplication="true"/>
      <Channel className="org.apache.catalina.tribes.group.GroupChannel">
            <Membership className="org.apache.catalina.tribes.membership.McastService"
                                   address="224.5.0.1"
                                   port="45564"
                                   frequency="500"
                                   dropTime="3000"/>
           <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
                            address="auto"
                            port="4000"
                            selectorTimeout="5000"
                            maxThreads="25"/>
           <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
                 <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
           </Sender>
           <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
           <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
           <Interceptor className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>
</Channel>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>

(In reply to andrew jardine from comment #2)
> Perhaps I have configured my cluster incorrectly? -- here is my configuration.
>
> [snip]

You need N > 0 nodes to make a cluster. Are they all configured identically? Maybe you have one of them still running BackupManager.

I have tried this with 2 nodes all the way up to 5 nodes -- all configured the same, all the same results. The odd thing is that it only seems to affect sessions that are marked as Primary on the node that is being shut down. For example.

Node A                         Node B
session 1 (primary)            session 1
session 2                      session 2 (primary)
session 3                      session 3 (primary)
session 4 (primary)            session 4 
session 5 (primary)            session 5


If at this point I shutdown Node B, then session 2 and session 3 on Node A will be destroyed leaving me with -

Node A                         Node B
session 1 (primary)            
session 4 (primary)            
session 5 (primary)            

... but all nodes that were not primary do not appear to be sending the "SESSION EXPIRE" message to the cluster. 

I'll try to get that thread dump for you when I get a bit of breathing room at work.

You are missing:

<ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener">

I've just confirmed with my 4-node test cluster and the latest 7.0.x code that - providing this is present - the sessions fail over correctly when the current primary node is shutdown gracefully.

Hey Mark,

Sorry for the delay -- other priorities came up. I'm trying this again right now, though I think I tried that as well already. Could be though that I did not have the session replication configured correctly when I tried it. If memory serves, this is what we found (though I am double checking this morning)

1. We set the jvmRoute attribute on the <Engine /> envelope. Node 01 had a value of jvmRoute="01", Node 02, a value of jvmRoute="02" etc.

2. We configured Apache to use a sticky session based on the jSessionID.

3. This worked and my first request when to Node 01 so I ended up with a session id similar to :: ABCD1234567890-01

4. All my subsequent traffic was routed to the 01 server.

5. Shutdown 01.

6. Apache started directing my requests to 02 -- but my jSessionID was now post-fixing the 02 jvmRoute value so I had -- ABCD1234567890-02 

7. Node 02 did not find a session with that ID, so it was creating a new session. 

-- again, I could have not had the replication working properly perhaps so I'll do some more testing today and update this ticket with anything I find.

Hey Mark,

UPDATE:

I am seeing the same behaviour, even with the JvmRouteBinderValve. At first I enabled the jvmRoute, but that was problematic because, as previusly mentioned, the route was post fixed to the sessionid. I removed the jvmRoute, but LEFT the JvmRouteBinderValve and restarted everything.

Session replication works. I have my 3 nodes behind an apache proxy that does RR load balancing to each of the nodes. When I shut down a node from the cluster, sometimes the session remains, other times it is lost. It appears, again, as though the primary node shut down is the problem.

For my requirements, the only time I would want a session expiration to be broadcast across the cluster is when a user logs out. The application handles this for me already so for Tomcat, the application server need only kill its own list of sessions on shut down. Perhaps my scenario is something that is outside the norm of what others/tomcat expects. Either way, the only solution I have found to date is to modify that method so that it does not default to broadcasting across the cluster.