[ http://jira.jboss.com/jira/browse/JBAS-830?page=history ]
Scott M Stark closed JBAS-830:
------------------------------
Resolution: Done
> Session Replication Inconsistent
> --------------------------------
>
> Key: JBAS-830
> URL: http://jira.jboss.com/jira/browse/JBAS-830
> Project: JBoss Application Server
> Type: Bug
> Components: Clustering
> Versions: JBossAS-3.2.6 Final
> Reporter: SourceForge User
> Assignee: Scott M Stark
>
>
> 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
