Session Replication Inconsistent

SourceForge Submitter: airsquig .
This Bug report is a result of discussions on the JBoss
Forums:
http://www.jboss.org/index.html?
module=bb&op=viewtopic&t=43602

Versions Replicated on:
JBoss 3.2.3, JBoss 3.2.2, JBoss 3.2.4 RC, JBoss 4.0
RC
Version researched:
JBoss 3.2.4 nightly
Overview:
It was noticed that HTTP Session Replication appeared
inconsistent in a clustered environment. Further
research showed that this was happening under round
robin load balancing.

Basically, it was found that a Session would replicate to
another node ONCE and only Once, after that, the
sessions are inconsistent.

This shows itself in a apache round robin, NON Sticky
load balanced configuration. On the third hit is when
this bug shows itself.

Now, after adding some trace, what I found is the
following:
It seem that the
org.jboss.web.tomcat.session.ClusterManager has a
local session container(sessions). If and only if the
session is not in the local container, it will access the
HTTPSessionMBean to get the session, which calls the
org.jboss.ha.httpsession.beanimpl.ejb.ClusteredHTTPSes
sionBeanImpl EJB. All works well. If node A is hit first,
then Node B, Node B will get the session from the EJB
that was set from node A.

Now, Once both nodes have the session in their cache,
the ClusterManager does not appear to go back to the
MBean to re-get their session on get session requests, it
just uses the version in local sessions container. This
means that a session will replicate ONCE, and after
that, tomcat uses its local version. This causes an
inconsistent session state.

It does look like each Servlet Container is updating
there version in the EJB but, it is off because it is based
off the inconsistent session it its local cache.

Now, to test this, I made a quick code change to
ClusterManager.findSession()method to get the session
from the MBean and not use the one from sessions.
This appeared to fix the problem (You have to call
sessions.sessions.get(id) or it will break. Again, I did
not spend much time on fixing it). Exactly how you
want to fix this is up to you, I can see a few ways:

1. Somewhat like mentioned above.
2. Making the backend call the invalidate on
the MBean to get rid of the sessions session.
3. others.

Reproduction Information:

This can be replicated by 1 JSP in a clustered
environment in a session replicated web application.
The attached JSP will replicate this problem. Basically,
on each cluster, change the string being appended to
the session key to the node name.
In an apache round robin environment, one would
expect that the string in the session would look like the
following:
Hit1:
NodeA
Hit2:
NodeA,NodeB
Hit3:
NodeA,NodeB,NodeA
Hit4:
NodeA,NodeB,NodeA,NodeB
Hit5:
NodeA,NodeB,NodeA,NodeB,NodeA

Right now, this is what happens:
Hit1:
NodeA
Hit2:
NodeA,NodeB
Hit3:
NodeA,NodeA
Hit4:
NodeA,NodeB,NodeB
Hit5:
NodeA,NodeA,NodeA
Hit6:
NodeA,NodeB,NodeB,NodeB

Now, you do not necessarily need the apache round
robin configuration but, it helps. Email me if you have
any questions.

Jason