8 Replies Latest reply on Jul 24, 2009 12:51 PM by ips

    EJopr meets its evil twin!

    peterj

      Amaze your family and friends! Bring up two instances of JBoss AS 5.1.0.GA, using the default ports for one and using the ports-01 settings for the other. Bring up the admin console for both instances. Sign into the first and do some stuff. Then sign into the second and do some stuff. Then go back to the first and try to do anything and you get the login screen.

      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.

      Running multiple instance but binding the instances to different IP addresses does not exhibit this problem - the admin consoles don't trip over each other.

        • 1. Re: EJopr meets its evil twin!
          ips

          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

             

            "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

               

              "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

                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.

                • 5. Re: EJopr meets its evil twin!
                  peterj
                  • 6. Re: EJopr meets its evil twin!
                    ips

                    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

                      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

                        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".