Session Failover in Jboss 5.1.0

[choona_pk]

Hello,

I am using Jboss 5.1. I have configured Virtical clustering in a multihomed System. I have 2 noded bound to 2 different IPs.

I am using apache with mod_jk to load balance requests. I have session replication enabled in web.xml with <distributable/> tag. Now the problem I am facing is that we have an application, after loggin in to it, a session is established with any one of the 2 nodes. I want this session to failover to the other node in case of the fist node failure.

To test the session failover I used two different Browsers:

With Firefox:

session is established after loggin in to application, the session is established with node1. I kill the process for node 1. After 10 or so seconds the request goes to the Node2 but the application sends me back to login screen. (means the session is broken).

With Internet Explorer:

Session is established after logging in to application, the session is established with node1. I kill the process for node1. After 10 or so seconds, the request goes to the Node2 but instead of sending me to login screen as experienced with firefox, the application lets me do operations normally. (means session is not broken).

Now I want to know why is this happening? IE is not making any issue but firefox does Is there anything different in both browsers that handle sessions differently??

[pferraro]

There should be no difference in behavior per browser.  If the session from the 1st request was replicated successfully (this is done on the server side), then the failover node will be able to associate the requested session id with the replicated session with no problem.  My hunch is that during your firefox test, the 1st node was killed before the session had a chance to replicate (replication is asynchronous by default).  The fact that you saw different behavior from 2 different browsers was just a coincidence.

[choona_pk]

Thanks Paul for your reply, I captured packets during these tests and found that there was nothing unusual in both the cases. It turned out to be the Application's fault. Apparently the development team could not handle the session properly in the application.

Thanks.