[Bug 57532] Session expire message sent to cluster nodes even with DeltaSession configuration not to
https://bz.apache.org/bugzilla/show_bug.cgi?id=57532 --- Comment #6 from andrew jardine andrew.jard...@jardineworks.com --- 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. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57532] Session expire message sent to cluster nodes even with DeltaSession configuration not to
https://bz.apache.org/bugzilla/show_bug.cgi?id=57532 --- Comment #7 from andrew jardine andrew.jard...@jardineworks.com --- 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. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57532] Session expire message sent to cluster nodes even with DeltaSession configuration not to
https://issues.apache.org/bugzilla/show_bug.cgi?id=57532 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |INVALID --- Comment #5 from Mark Thomas ma...@apache.org --- 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. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57532] Session expire message sent to cluster nodes even with DeltaSession configuration not to
https://issues.apache.org/bugzilla/show_bug.cgi?id=57532 --- Comment #4 from andrew jardine andrew.jard...@jardineworks.com --- 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 receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57532] Session expire message sent to cluster nodes even with DeltaSession configuration not to
https://issues.apache.org/bugzilla/show_bug.cgi?id=57532 --- Comment #3 from Christopher Schultz ch...@christopherschultz.net --- (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. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57532] Session expire message sent to cluster nodes even with DeltaSession configuration not to
https://issues.apache.org/bugzilla/show_bug.cgi?id=57532 --- Comment #2 from andrew jardine andrew.jard...@jardineworks.com --- 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 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 57532] Session expire message sent to cluster nodes even with DeltaSession configuration not to
https://issues.apache.org/bugzilla/show_bug.cgi?id=57532 andrew jardine andrew.jard...@jardineworks.com changed: What|Removed |Added Keywords||APIBug CC||andrew.jardine@jardineworks ||.com -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
