Bug 56578

Created attachment 31678 [details]
session.jsp

Created attachment 31679 [details]
invalidate.jsp

For reference: the thread on users@,
"Tomcat 7.0.54 - Session invalidate broken in some apps"
http://tomcat.markmail.org/thread/3zjrbavcxgrnw3ga

WORKSFORME:

I placed both files into webapps/examples/
I added the following line to session.jsp to display current session id:
<tr><td>Session ID:</td><td><%= session.getId() %></td></tr>

I am using a single Tomcat instance, with default configuration.
I added the following line added to server.xml.
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>

I do not see any error. The session creation time is updated on invalidation, and session id is changed as well.

Tested with current 7.0.x (JDK 6u45) and 8.0.x (JDK 7u55),
on Win7, Firefox 29.0.1,


A fragment of catalina.date.log of Tomcat 7 (at start time):

31.05.2014 0:02:35 org.apache.catalina.ha.tcp.SimpleTcpCluster startInternal
INFO: Cluster is about to start
31.05.2014 0:02:35 org.apache.catalina.tribes.transport.ReceiverBase bind
INFO: Receiver Server Socket bound to:/xxx.yyy.z.www:4000
31.05.2014 0:02:35 org.apache.catalina.tribes.membership.McastServiceImpl setupSocket
INFO: Setting cluster mcast soTimeout to 500
31.05.2014 0:02:35 org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Sleeping for 1000 milliseconds to establish cluster membership, start level:4
31.05.2014 0:02:36 org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Done sleeping, membership established, start level:4
31.05.2014 0:02:36 org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Sleeping for 1000 milliseconds to establish cluster membership, start level:8
31.05.2014 0:02:37 org.apache.catalina.tribes.membership.McastServiceImpl waitForMembers
INFO: Done sleeping, membership established, start level:8
31.05.2014 0:02:37 org.apache.catalina.ha.session.JvmRouteBinderValve startInternal
INFO: JvmRouteBinderValve started


Did you use a single Tomcat instance in your reproduction scenario, or I need something more complex?

Did your cluster startup log looked like the above?

Does your configuration have other differences from the default one (besides the added line in server.xml)?

Can you try debugging? (As mentioned in the e-mail thread).

On a hunch, I tested a webapp with and without the <distributable/> element.

The webapp also needs to have that element in the web.xml to reproduce the issue and the examples webapp does not have it.

FWIW environment is CentOS 6.5, Java 7u55 and Chrome 35, but I don't think any of those factors matter.

Ack. Thank you!
It is reproducible with 8.0 if I add <distributable/> to examples/WEB-INF/web.xml.

This regression is caused by StandardSession change in r1584915
(a fix to bug 56339)

The session object is DeltaSession.
The sequence of events is:

1. session.invalidate() = StandardSession.invalidate() -> calls expire()
2. expire() is implemented as expire(notify=true)
3. DeltaSession.expire(notify) is implemented as expire(notify=true, notifyCluster=true).

4. DeltaSession.expire(boolean notify, boolean notifyCluster)
- sets "expiring = true"
- does cluster.send(msg);
- calls super.expire(notify);

Here the things go wrong. Because of the change in r1584915 the StandardSession.expire(notify) checks the "expiring" flag and exits immediately. Effectively that call became a NOOP.

Thus the actual expiration does not happen.

Thank you for tracking it down. That was one of the possible suspects I had looked at while reviewing the changelog for possible regressions.

This has been fixed in 8.0.x for 8.0.9 onwards and in 7.0.x for 7.0.55 onwards.