jboss cluster session replication not working (multiple jsessionid cookies)

Question

I'm trying to authenticate on my web application deployed on a jboss working in cluster mode with 2 nodes.

After a succesful authentication I get redirected to an admin page where a Filter checks if I am logged in.

On standalone mode it works just fine but when I deployed into production, which uses cluster mode, the filter rejects my request because it can't access the session parameters I have established on authentication.

Using the developer tools I see there are 3 JSESSIONID cookies set: one for /, one for /myapplication path and another one called JSESSIONID-34234 also for /myapplication path (I've cleared all them before starting the process).

Browsing the jboss docs I can't see no explanation for this although it seems the source of my problem.

How can I get to work authentication (I am using spring security http form based authentication) in my JBoss cluster?

Answer 1

Solved by enabling sticky session by adding the following to the virtualhost configuration file:

Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/myapplication" env=BALANCER_ROUTE_CHANGED
<Proxy balancer://jboss6-hc-001-8109>
  BalancerMember ajp://jboss2.imatiasl.lan:8109 route=jboss2-hc-001-server-02
  BalancerMember ajp://jboss3.imatiasl.lan:8109 route=jboss3-hc-001-server-02
  ProxySet lbmethod=byrequests stickysession=ROUTEID
</Proxy>

Answer 2

Web session clustering should work if:

1. You enabled <distributed/> in web.xml.
2. Your app's server group is using ha or full-ha profile

If you want your clustered app perform better, consider implementing a good load-balancing policy. For most webapps load-balancing with sticky sessions is OK.

In some webapps, it is enough not to ask for re-authentication in case of failover or session is very easy to rebuild if authentication info is available. In such cases you even don't need web session clustering. Clustered SSO is enough, the caveat is you'll have to use container level security for authentication (most probably supported by spring-security). This way only authentication info is replicated, so you'll have to design session data management to be resilient to situations, when session suddenly becomes empty.