You mean rebooting all of the cluster nodes? Or just one node? If the former, you should get a new session unless the browser or edge server caches it. If the later, yes you will get the old session back because it will retrieve the old state from the other group member (actually coordinator).
Ok, that may be good, but what about the real problem I mentioned? I quote it here below:
That would not be bad, except that now a user can see the session of a different previous user!!!! I suppose this is due the fact that the container assigned to the user the same session ID of another user prior the reboot, but I did not investigate further.
Did you ever face something similar?
If you don't mind you may try the following: opening two browser (IE), logging in as user_a in the first, and as user_b in the second. Populate your session performing some actions. Don't log out nor shut down the browsers and restart the server. After the reboot try to perform some action. When re-promped swap the users (user_b in the first and user_a in the second) and look if tou have the same problem. If not, probabily I'm doing something wrong with my app.
I'm using Struts 1.1 and form authentication.
What replication granularity are you using: SESSION or ATTRIBUTE?
This is the setting I'm using in jboss-web.xml:
<replication-config> <replication-trigger>SET_AND_NON_PRIMITIVE_GET</replication-trigger> <replication-granularity>ATTRIBUTE</replication-granularity> </replication-config>
The file tc5-cluster-service.xml is unchanged
Do you have a simple war I can use to test this? I want to do as you suggest, but don't have the spare cycles to build up the war in the next few days.
If you do, please open an issue at jira.jboss.com (project JBoss Application Server -- not JBoss Clustering) and attach the war to it.
I'll do it ASAP