Bug 48717 - Session listeners not called on cluster node start
Session listeners not called on cluster node start
Product: Tomcat 5
Classification: Unclassified
Component: Catalina:Cluster
PC Linux
: P2 regression with 2 votes (vote)
: ---
Assigned To: Tomcat Developers Mailing List
Depends on:
  Show dependency tree
Reported: 2010-02-09 17:43 UTC by David Rees
Modified: 2011-08-16 12:44 UTC (History)
0 users

Adds sessionDidActivate calss (3.54 KB, text/plain)
2011-02-18 06:45 UTC, Mark Thomas

Note You need to log in before you can comment on or make changes to this bug.
Description David Rees 2010-02-09 17:43:14 UTC
This appears to be a regression from an earlier bug #35916 which describes the exact same problem, but somewhere along the way, it appears that the bug has come back.

Basically, once Tomcat is put in to a cluster and a node joins the cluster, the webapp isn't notified via either HttpSessionActivationListener.didActivate or HttpSessionListener.sessionCreated.

Otherwise, all nodes seem to receive these events as expected once in the cluster.

This is a problem for an application which needs to track all currently active sessions as it will not know of any existing sessions when joining a cluster.

This also appears to affect Tomcat 6.0.24 as well where the symptoms are the same.

I actually posted to the users list almost a year ago (totally forgot I did that until I was searching the archives again), but didn't hear any response and worked around the issue temporarily, but it has come up again so I posted to the list again, but no response either time.

Comment 1 Mark Thomas 2010-03-28 19:42:34 UTC
Confirmed and fixed in trunk for 7.0.x

I have proposed the same fix for 6.0.x and 5.5.x
Comment 2 Mark Thomas 2010-05-05 17:54:37 UTC
This has been fixed in 6.0.x and will be included in 6.0.27 onwards.
Comment 3 David Rees 2010-05-05 18:01:33 UTC
Is there any chance you'll also be backporting to 5.5.x as well?

Appreciate the updates...
Comment 4 Mark Thomas 2010-05-05 18:05:34 UTC
As per comment #1, it has been proposed for 5.5.x. When it gets enough votes, it will be committed.
Comment 5 Mark Thomas 2010-05-18 13:17:12 UTC
This has been fixed in 5.5.x and will be included in 5.5.30 onwards.
Comment 6 David Rees 2011-02-09 19:29:32 UTC
I never got a chance to test that this was fixed until now, but testing on 5.5.32 still does not appear to work.

How I'm testing:

Two Linux systems running Tomcat 5.5.32 with a Cluster defined in the Host section like this:

<Cluster className="org.apache.catalina.cluster.tcp.SimpleTcpCluster" receiver.sendAck="false" sender.waitForAck="false" sender.doTransmitterProcessingStats="true" sender.queueDoStats="true" sender.queueTimeWait="true">
<Valve className="org.apache.catalina.cluster.tcp.ReplicationValve" filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;"/>
<Valve className="org.apache.catalina.cluster.session.JvmRouteBinderValve" enabled="true"/>
<ClusterListener className="org.apache.catalina.cluster.session.ClusterSessionListener"/>
<ClusterListener className="org.apache.catalina.cluster.session.JvmRouteSessionIDBinderListener"/>

The application has a <listener><listener-class> defined in the web.xml which implements ServletContextListener and HttpSessionListener.  The HttpSessionListener methods work fine on each node.

The application adds an attribute to a session which implements HttpSessionActivationListener, HttpSessionBindingListener and Serializable.  The HttpSessionBindingListener methods work fine on each node.

When restarting a node, the session attribute never receives any calls to sessionDidActivate when that node comes back online.

Let me know if you need any more details.
Comment 7 Mark Thomas 2011-02-18 06:45:45 UTC
Created attachment 26679 [details]
Adds sessionDidActivate calss

The previous fix handled session creation/destruction but not activation
Comment 8 David Rees 2011-02-24 17:48:44 UTC
Thanks - so I guess to test this I'd have to apply the patch to Tomcat source and build it myself?
Comment 9 Mark Thomas 2011-02-24 17:52:52 UTC
'fraid so.
Comment 10 Mark Thomas 2011-08-16 12:44:45 UTC
This has been fixed in 5.5.x and will be included in 5.5.34 onwards.