-
1. Re: EJopr meets its evil twin!
ips Jun 12, 2009 7:49 AM (in response to peterj)Hi Peter,
I cross-posted this to the Seam forum and got a response that the behavior is a result of the way JBAS generates JSESSIONIDs. See:
http://www.seamframework.org/Community/SessionsConflictForSameAppOnTwoDifferentASInstancesOnDifferentPorts
-Ian -
2. Re: EJopr meets its evil twin!
ccrouch Jun 12, 2009 7:53 AM (in response to peterj)"PeterJ" wrote:
It would appear that the Seam feature to track multiple windows for an app doesn't use the port number in its tracking mechanism, so it gets confused, and the admin consoles end up tripping over each other.
I'm not quite sure how the apps could be tripping over each given they are running in completely self contained instances, perhaps its the client side state which is getting trampled.
Peter, can you raise a blocking jira for this (https://jira.jboss.org/jira/browse/EMBJOPR), and include in there which config you used as the base for the ones you tested with, and exactly how you started the instances.
Thanks -
3. Re: EJopr meets its evil twin!
ccrouch Jun 12, 2009 7:56 AM (in response to peterj)"ips" wrote:
I cross-posted this to the Seam forum and got a response that the behavior is a result of the way JBAS generates JSESSIONIDs.
Interesting. Lets please still raise an EMPJOPR jira for this as I'd like a dedicated place for workarounds and/or solutions.
Thanks -
4. Re: EJopr meets its evil twin!
jfclere Jun 12, 2009 8:23 AM (in response to peterj)The browser sends the sessionid and it get reused in AS.
Use JVMRoute or set org.apache.catalina.connector.Request.SESSION_ID_CHECK to true. -
-
6. Re: EJopr meets its evil twin!
ips Jul 24, 2009 10:55 AM (in response to peterj)I have reproduced the issue.
The browser sends the sessionid and it get reused in AS.
Use JVMRoute or set org.apache.catalina.connector.Request.SESSION_ID_CHECK to true.
I tried the following workarounds:
A) Tell Tomcat to append "alpha" and "beta" to the end of the cookie content (e.g. "BF6B60CCE106377EB8909F245D397099.alpha").
1) Pass -DjvmRoute=alpha when starting server #1 (listening on port
8080).
2) Pass -DjvmRoute=beta when starting server #2 (listening on port
8180).
B) Not sure exactly what this was supposed to do - the documentation I found (http://www.jboss.org/file-access/default/members/jbossweb/freezone/docs/latest/sysprops.html) wasn't very specific.
1) Pass -Dorg.apache.catalina.connector.Request.SESSION_ID_CHECK=true when starting server #1 (listening on port
8080).
2) Pass -Dorg.apache.catalina.connector.Request.SESSION_ID_CHECK=true when starting server #2 (listening on port
8180).
C) Tell Tomcat to use alternate session cookie names ("alpha" and "beta", rather than "JSESSIONID").
1) Pass -Dorg.apache.catalina.JSESSIONID=alpha when starting server #1 (listening on port
8080).
2) Pass -Dorg.apache.catalina.JSESSIONID=beta when starting server #2 (listening on port
8180).
Neither A nor B solved the issue. C did.
Is there something I should have done differently for A or B? Are there any other nicer solutions to this issue? It's a shame the port isn't included in the cookies. Is there any way to tell Tomcat to somehow include the port? -
7. Re: EJopr meets its evil twin!
jfclere Jul 24, 2009 11:42 AM (in response to peterj)You need A) + B)
C) will also do it but the specs says the cookie used to store the sessionid should be JSESSIONID. -
8. Re: EJopr meets its evil twin!
ips Jul 24, 2009 12:51 PM (in response to peterj)I tried A+B, but that didn't do the trick. I monitored the cookies in FF, and I still saw the cookie from server1's session get clobbered by the cookie for server2's session once I logged into server2, since both cookies were still named "JESSIONID".