JSessionID and Clustering

[wrfeldmann]

Everyone,

We have the following senerio happening:

1 application running on 2 servers with a separate hardware loadbalancer doing round robin load balancing.

Clustering is up and running after a successful login.  I can bring down one node of the cluster and the user does not know it happened.

Problem:

There are times when you request the login page and get the JSESSION cookie, but when you submit the form, it goes to the other node and because the other node doesn't know about the JSESSION, you get a 400 error returned.

What do I need to do to make this stop happening.  The load balancer does not support Sticky Sessions.

Thanks,

Rick

[smarlow]

Rick,

Take another look at the hardware load balancer documentation for sticky session support, they might of called it something else.  Google searching for your LB vendor name and sticky sessions, might help you find it.

Good luck,

Scott

[brian.stansberry]

Some vendors use the terms "session persistence" or "persistent sessions".

[wrfeldmann]

Based on the replies, further investigation on the load balancers shows that it does support multiple methods of persistence.

However, we have a custom written sso process that brings up another problem.  While persistence would direct the user to the same server every time, it doesn't mean that the sso module will hit the same server when it log into the application.  Let me provide more details.  We have 2 applications (app1 and app2) running on 2 servers (server1 and server2) behind a load balancer.

Now, when a user requests the login page, the load balancer will direct them to app1 on either server1 or server2.  When the user has completed filling out the login form and hits submit, they could then go to app1 on either server1 or server2.  "Sticky Sessions" would make sure that they got back to the same server of their initial request.

Now, app1, running on either server, issues a login request to app2 on either server1 or server2.  Upon successful login, app1 redirects the user to app2.  The redirect will automatically tell the browser to request app2 and the load balancer will send that request to either server1 or server2.  Again, with sticky sessions, the user will go the the same server of their original request.  But, the login request is being initiated by a different "user" and might go to a different app2 server.  When the redirect request comes back in from the user, they may or may not be sent to the same app2 server that app1 logged them into, and since the cluster hasn't sync'd, they will either get the welcome page (or bookmarked page) if the login server was the same as the sticky server, or they will get the login page from app1.

So, how can this dilemia be resolved?

Thanks,

Rick