1 Reply Latest reply on Aug 26, 2003 2:44 PM by mtb2ride

    HTTP Session failover, A one shot deal, Jboss3.2.1 Tomcat &

    mtb2ride

      After getting a simple Jboss cluster set up on 2 Solairs nodes, the HTTP session failover is not functioning properly. I set up JBoss 3.2.1 on a cluster of 2 Solaris boxes with an Apache 1.3.27 - jk2 load balancer. This in of itself took a few hours and I used the following thread for most of my setup questions http://www.jboss.org/modules/bb/index.html?module=bb&op=viewtopic&t=

      My webapp has a simple jsp that does a httpSession.setAttribute("myHashSet", hashSet) on every invocation. hashSet contains a set of Strings, a new string added during each invocation of the jsp. Since I use stickySession=1 for the loadbalancer, the initial node fielding the request handles all subsequent requests unless that node becomes unavailable.

      In my example the sticky session ensures all requests go to "node1". Then I pull "node1" out by simply shutting JBoss down. This works just fine, all data in the session is replicated to the new node "node2". Now, let me try this again, starting out with "node1" handling the requests, then force a failover to "node2" by simply taking "node1" out of the cluster (setting disabled=1 for node1 in workers2.props). With load now directed at "node2" the session data replicated from "node1" is available, good!. Finally, I add data through "node2", then force a failover again, this time to "node1" (disabling "node2" and enabling "node1", again using workers2.props). After the second failover the data is no longer replicated. In other words, the data that I entered on "node2" is not available after the second failover to "node1".

      node1(enter A, B) --failover--> node2 (A, B still there, now enter C) --failover--> node1( only A, B available)

      Sorry this is so complicated, describing behavior in clustered environments always is, I couldn't imagine trying to describe this using more than 2 nodes.

      The conclusion I have come to is, JBoss HTTP session replication is a one shot deal. The data in a replicated session should be replicated to all nodes. In this case both nodes were running throughout the test, each was logging HttpSessionHA messages indicating that replication was taking place. But the replicated data seems to only be recoverable once after the first failover.

      Could anyone provide some information about how to achieve multiple failovers?

      Steve

      ===== SETUP INFO================================

      My configuration consists of:

      mod_jk2:

      [lb:lb2]
      debug=6
      timeout=30
      attempts=3
      stickySession=1

      [channel.socket:txsldevnode01:8009]
      debug=6
      tomcatId=node1
      lb_factor=100
      group=lb2
      disabled=0

      [channel.socket:txsldevnode02:8009]
      debug=6
      tomcatId=node2
      lb_factor=100
      group=lb2
      disabled=0

      # Uri mapping
      [uri:/mytestweb/servlet/*]
      group=lb2
      [uri:/mytestweb/*.jsp]
      group=lb2

      using the "all" configuration set:
      all/deploy/jbossweb-tomcat.sar/META-INF/jboss-service.xml
      <Engine .... jvmRoute="node1"> & <Engine .... jvmRoute="node2">
      instant

      Both nodes have an entry in /etc/hosts for resolving each other, and I'm not using IP address in any configuration including Apache or jk2.

      My webapp has a simple jsp that does a httpSession.setAttribute("myHashSet", hashSet) on every invocation. hashSet contains a set of Strings, a new string added during each invocation of the jsp. Since I use stickySession=1 for the loadbalancer, the initial node fielding the request handles all subsequent requests unless that node becomes unavailable.

        • 1. Re: HTTP Session failover, A one shot deal, Jboss3.2.1 Tomca
          mtb2ride

          I have more info on this issue:

          The issue I described regarding JBoss session replication as being a one shot deal still exists for me. I did realize going back and reading this post that I was simulating server failure by disabling & enabling nodes through the MOD_JK loadbalancer. If I were to do a "true" test by actually stopping server1 for the first failover then bring server1 back up and stop server2 for the second failover, multiple failovers should work. I come to this conclusion because the act of bringing a sever into the cluster forces the data currenlty in the session to be replicated through a JavaGroups Multicast.

          Currently, I am using the JBoss HTTP session replication as is, because if a node in my cluster fails no users will be put out any more than having to re-login.

          If anyone is at a stage where they can run a "true" test, please try it out and let me know.


          Thanks
          Steve