1 2 Previous Next 19 Replies Latest reply on Oct 27, 2002 12:23 PM by AB

    HTTP in-memory session replication

    Jorju Newbie

      Hi all,

      does jbossha-httpsession.sar work ok ? (i believe not)

      I've got the ClusteredHTTPSessionService up and running.

      But session does not get replicated !!!

      (I'm running 2 Jboss-3.0.1/tomcat-4.0.4 bundle on LinuxRH
      on 2 different machines)

      session replication works well with both of these
      tomcats (the ones bundled with jboss)!!! (using javagroups.jar v2.1, tomcat-javagroups.jar and UDP protocol stack for InMemoryReplicationManager)

      i've tried all possible combinations with both
      jboss (and their tomcat4-service.xml) but seems like JBoss handles by itself session replication
      (through jbossha-httpsession.sar) witn no success (and
      worst, with no logs, traces that explain such a session replication problem)

      additionally,
      putting distributable property in web.xml will cause
      to loose session afinity ! (loosing sticky sessions)
      (and session still won't replicate !!!)

      Is anyone in a similar situation ?
      Does someone know what is happening with jbossha-httpsession.sar ?

      Thanks in advance

        • 1. Re: HTTP in-memory session replication
          Bob OMalley Newbie

          I have gotten jbossha-httpsession.sar to work a bit on a windows 2000 box. So far, my testing has been with two different server instances running on the same box. The session does replicate back and forth for me. Placing the 'distributable' in the web.xml file did not break anything.

          I have a different problem (described in my thread earlier today). Session affinity is broken for me because I am using the Tomcat supplied isapi_redirect.dll for forwarding requests from IIS to JBoss (it's handshake is the same as the apache redirector I think). That redirector requires that Tomcat append a token at the end of each JsessionId cookie -- the token being a name unique to the server and configured using a jvmRoute setting in the server configuration. You can see the token when you do a session.getID().

          I can see in the code for org.jboss.ha.httpsession.server.ClusteredHTTPSessionService.java that it has a method called generateSessionId() which makes no attempt to append the token. I am tempted to go in and patch my copy of this module (as well as altering org.jboss.web.catalina.EmbeddedCatalinaServiceSX to send in a jvmRoute property) to fix the problem but right now I am waiting to see if we're going to use this at our organization (for other reasons) and to see what Sacha says about it.

          Bob

          • 2. Re: HTTP in-memory session replication
            Thomas Peuss Newbie

            Hello!

            DON'T DO THIS in org.jboss.ha.httpsession.server.ClusteredHTTPSessionService.java!!!

            This service is used by Tomcat AND Jetty - so if you wan't to change something please do it in the Tomcat-service code. I think the thing with jvmRoute is a BUG in the tomcat-clustering code - so it is my job to iron it out... ;-) Any patch from your side is welcome. If you have one send it to me.

            CU
            Thomas

            • 3. Re: HTTP in-memory session replication
              Thomas Peuss Newbie

              The clustering code now respects jvmRoute - the patch is in HEAD and Branch_3_0...

              Please try it...

              CU
              Thomas

              • 4. Re: HTTP in-memory session replication
                Bob OMalley Newbie

                Great!

                Today I am having trouble building both the JBoss3_0_1RC1 branch and the HEAD branch -- getting an error in javax.security.auth.login.LoginContext.java module (can't resolve symbol '.module' in class javax.security.auth.login.AppConfigurationEntry) Not sure if it's because I'm now using jdk1.4.1RC or what.

                The clustering folder builds fine, as does the catalina folder (except it only generates the jboss-service.xml file). Are there specific deployable modules that I could build and place in my JBoss3_0_1RC1 deployment?

                Thank you.

                Bob



                • 5. Re: HTTP in-memory session replication
                  Bob OMalley Newbie

                  Thanks!

                  For some reason, I can't get the JBoss3_0_1RC1 branch built today -- getting an undefined symbol in javax.security.auth.login.LoginContext -- can't find '.module' in the class AppConfigurationEntry. Same problem building HEAD. I've recently switched to jdk1.4.1RC so don't know if that's my problem.

                  However if could point me to which modules have changed, perhaps I can build those and deploy them into my regular RC1 release. cluster builds but the catalina folder doesn't build the tomcat4-service.jar

                  Bob

                  • 6. Re: HTTP in-memory session replication
                    Jorju Newbie

                    Hi

                    >The clustering code now respects jvmRoute - the patch is >in HEAD and Branch_3_0...

                    >Please try it...

                    I've just try it out, ... but
                    unfortunately,
                    that did not solve my initial problem
                    (session still doesn't get replicated :-(

                    Thanks for your interest

                    • 7. Re: HTTP in-memory session replication
                      Jorju Newbie

                      Seems the new sources solved my problem

                      but ...
                      session failback isn't yet achieved !

                      that means,
                      - load balancing and session afinity seem now to work
                      the right way
                      (i.e. SessionIds Sad06NhOOs91G9qEk+gflw**.server1)
                      - launch the 2 clustered-servers and fill the session of one of them: we'll call this server "server1"
                      (although i have debug="99" in most xml i cannot
                      see any session replication logs :-(
                      - stop server1
                      - try to continue filling your session (using the same
                      sessionId)
                      - yujuuuuu !, session is being replicated
                      (although i still haven't got any logs that confirms it)
                      - now launch again the dead server ("server1")
                      when it finishes launching it should replicate the
                      current session in server2 but...
                      - try to continue filling your session:
                      wops !, a new session ? where did my shopping cart go ?

                      is it session failback already implemented ?

                      Thanks

                      • 8. Re: HTTP in-memory session replication
                        Jorju Newbie

                        One more thought ...

                        i was so happy to see that, finally, the session get
                        replicated that i deleted jvmRoute="worker_as_in_workers.properties_name"
                        from tomcat4-service.xml to force the lost of
                        session affinity

                        i believed that (as session was now replicated) session
                        affinity was useless (without taking into accout performance boost) from a theoric point of view.

                        but, i was very disappointed to see that losing session
                        affinity also causes to loose session replication :-(

                        so, my final situation is:
                        session affinity + HTTP in-memory session replication + without session failback ! :-(

                        is there such a way to improve this situation ?

                        • 9. Re: HTTP in-memory session replication
                          Bob OMalley Newbie

                          With the fix, Sticky load balancing now works for me too.

                          I am able to see the sessionid with the appended jvmRoute:

                          6QSANdMh-X1ZOJYTWfxDgA**.serverOne

                          and when I shut serverOne off, the same exact session continues to be served from serverTwo! Yeah!

                          Fail Back seems to work for me. If I shut serverOne down, then hit the site in a session a few times (being served from serverTwo), then bring serverOne back up, the session continues to live -- it has a mind of it's own about whether it continues on ServerOne or ServerTwo but it does continue. Browser sessions that never were refreshed while serverOne was down will continue to be served with the correct session on serverOne after it comes back up. The first browser in after a server comes back up seems to be served from the failover server then bounces back to it's original server on the second refresh.


                          I'm scratching my head over the load balancing now -- the isapi_redirector.dll doesn't seem to round robin every other new session anymore when hitting a clustered site. It seems to stick with one of the servers for a while -- no matter if I start a dozen or so new web browsers. I'll have to look at it further. After either a period of time or when a server goes down and up, the entire load is directed to the other server. I'll do more testing.

                          Bob

                          • 10. Re: HTTP in-memory session replication
                            Jorju Newbie

                            Thanks for your answer,

                            > Fail Back seems to work for me. [...] it has a mind of
                            > it's own about whether it continues on ServerOne or
                            > ServerTwo but it does continue. Browser sessions that
                            > never were refreshed while serverOne was down will
                            > continue to be served with the correct session on
                            > serverOne after it comes back up.
                            > The first browser in after a server comes back up seems > to be served from the failover server then bounces back > to it's original server on the second refresh.

                            Session fail back doesn't work for me, even for browser
                            sessions that never were refreshed while server1 was down ! in all cases a new session is created in server1 !!

                            >i'm scratching my head over the load balancing now -- >the isapi_redirector.dll doesn't seem to round robin >every other new session anymore when hitting a clustered >site. It seems to stick with one of the servers for a >while -- no matter if I start a dozen or so new web >browsers. I'll have to look at it further.

                            The only difference i appreciate between our environments
                            must be isapi_redirector.dll's (i'm using mod_jk) load balancing & sticky session behaviour.
                            mod_jk manages load balancing by means of round robin
                            for every new session created to an alternative server).
                            (in my experience sticky balancing does affect the
                            "quality" of the new session round robin although i don't know how)

                            Do you have some logs that explicit the fact that when
                            serverOne returns to live somehow it copies the clustered
                            HTTP session ? Anyone does ?

                            • 11. Re: HTTP in-memory session replication
                              Thomas Peuss Newbie

                              The fact that server1 doesn't get the session back from server2 may be a bug.

                              The problem is that the session only gets replicated when it is modified (in my implementation after every request). The other nodes store the replicated sessions in a type of cache and they only look in the cache if they don't know the session. The http-cluster implementation does not ask the other nodes if they know the session.

                              I will have a look into this. Jetty clustering code is affected by this, too.

                              CU
                              Thomas

                              • 12. Re: HTTP in-memory session replication
                                Thomas Peuss Newbie

                                The fact that server1 doesn't get the session back from server2 may be a bug.

                                The problem is that the session only gets replicated when it is modified (in my implementation after every request). The other nodes store the replicated sessions in a type of cache and they only look in the cache if they don't know the session. The http-cluster implementation does not ask the other nodes if they know the session.

                                I will have a look into this. Jetty clustering code is affected by this, too.

                                CU
                                Thomas

                                • 13. Re: HTTP in-memory session replication
                                  Thomas Peuss Newbie

                                  The fact that server1 doesn't get the session back from server2 may be a bug.

                                  The problem is that the session only gets replicated when it is modified (in my implementation after every request). The other nodes store the replicated sessions in a type of cache and they only look in the cache if they don't know the session. The http-cluster implementation does not ask the other nodes if they know the session.

                                  I will have a look into this. Jetty clustering code is affected by this, too.

                                  CU
                                  Thomas

                                  • 14. Re: HTTP in-memory session replication
                                    Thomas Peuss Newbie

                                    The fact that server1 doesn't get the session back from server2 may be a bug.

                                    The problem is that the session only gets replicated when it is modified (in my implementation after every request). The other nodes store the replicated sessions in a type of cache and they only look in the cache if they don't know the session. The http-cluster implementation does not ask the other nodes if they know the session.

                                    I will have a look into this. Jetty clustering code is affected by this, too.

                                    CU
                                    Thomas

                                    1 2 Previous Next