Hello Filipe !
I'm wondering the same question we I saw your thread.
Do you have any news ?
Hi Filipe and Joao,
you are testing this wrong. In the step 5 you forgot to spoof your JSESSIONID cookie.
Can you describe better your idea ?
ok, but this is really intuitive if you know how sessions and cookies work in general. Look at the sources of the test app:
As you see it gets the clients session. This internally works looking at cookies and getting the JSESSIONID cookie, associates session and loads the state. Therefore in this step:
You go to 10.1.4.3 server and create your session, gets "stored" in your browser but then when you query 10.1.4.4 you session cookie is not there anymore because its different host, so you get brand new session.
To test it manually, there are 2 options:
- with spoofing -- query the first URL, copy the cookies information and query the second URL with the copied cookies
- use a load balancer -- so now they are both under same URL so if you shutdown one server backend, the other one will handle the request
You right, if i open the browser with ip of server, session it will be diferent.
But i did try on load balancer... i give up since i´ve no help here, and i putted as sticky session...
For enabling session replication I would make some little changes on your procedure:
Try deploying the WAR file (hsr-test.war) into one of the folders farm --> [JBOSS_HOME]\server\all\farm . Do it in just one server instance, if everything is working properly in the cluster, you should see how the WAR is replicated into the second server instance.
With this you have your application hsr-test in the cluster! both server instances run the application... however, for getting session replication you need to enable it into the application ("distributable" tag into the web.xml) --> http://docs.jboss.org/jbossclustering/cluster_guide/5.1/html/clustering-http.html#clustering-http-app
BTW, if you enable sticky session in the load balancer, the session replication in Jboss will be useful only if any of your instances in the cluster falls down... so if you think this is not a critical issue (maybe if one instance falls down it doesn't really impact on the business) do not use session replication. If sticky session is off in the balancer, session replication must be activated....