0 Replies Latest reply on Apr 27, 2011 12:14 PM by Nitin Bhardwaj

    Session-replication problem in JBoss 5.1 Failover/Clustering

    Nitin Bhardwaj Newbie

      Dear Friends,

       

      I am new to the interesting concept of JBoss Failover/Clustering. I decided to build a sample JSP/Servlet web-app (named XCLUST) in order to test this concept on JBoss 5.1. I referred Clustering Guide of JBoss.

      Background: I was able to set two nodes on a single non-multihomed server (my desktop connected to internet), and they were able to recognize each other in the cluster. I also set used mod_jk of Apache 2.2 server and configured it to handle the requests for XCLUST web-app which was deployed on both the nodes in the farm folder. However, when I take one node down the other node is unable to retrieve the same session which existed on first node and I am taken back to the login page of my application which should not happen if session is replicated successfully on the second node.

       

      Here is how I configured clustering at my desktop:

      1. Using two nodes on a single, non-multihomed server. Here are my run configurations for the two nodes (all, node2):

      run -c all -g NitCluster1 -u 224.0.0.1 -b 127.0.0.1-Djboss.messaging.ServerPeerID=1 -Djboss.service.binding.set=ports-default

       

      run -c node2 -gNitCluster1 -u 224.0.0.1 -b 127.0.0.1 -Djboss.messaging.ServerPeerID=2-Djboss.service.binding.set=ports-01

       

      2. In the web.xml of my web-application(XCLUST), I placed the entry <distributable/>

       

      3. The jboss-web.xml of my web-app looks like:

       

      <jboss-web>

          <security-domain>java:/jaas/nitstar</security-domain>

          <context-root>/XCLUST</context-root>

       

          <replication-config>

              <cache-name>standard-session-cache</cache-name>

              <replication-trigger>SET</replication-trigger>

              <replication-granularity>SESSION</replication-granularity>

              <replication-field-batch-mode>true</replication-field-batch-mode>

              <use-jk>true</use-jk>

              <max-unreplicated-interval>0</max-unreplicated-interval>

              <snapshot-mode>INSTANT</snapshot-mode>

              <snapshot-interval>1000</snapshot-interval>

          </replication-config>

      </jboss-web>

       

       

      Note that I've defined the security-domain above, and I've configured the application-policy in login-config.xml. I've also checked that login to application works fine.

       

       

      4. I've installed Apache server 2.2 with compatible mod_jk.

       

      5. The mod-jk.conf that has been modified by me in accordance with JBoss Clustering guide has been listed below:

       

       

      #Edited by Nitin with reference to JBoss Clustering guide

       

      # Load mod_jk module

      # Specify the filename of the mod_jk lib

      LoadModule jk_module modules/mod_jk.so

      # Where to find workers.properties

      JkWorkersFile conf/workers.properties

      # Where to put jk logs

      JkLogFile logs/mod_jk.log

      # Set the jk log level [debug/error/info]

      JkLogLevel info

      # Select the log format

      JkLogStampFormat "[%a %b %d %H:%M:%S %Y]"

       

      # JkOptions indicates to send SSK KEY SIZE

      JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories

      # JkRequestLogFormat

      JkRequestLogFormat "%w %V %T"

      # Mount your applications

      #Nitin: Mounting only XCLUST application

      JkMount /XCLUST/* loadbalancer

      # You can use external file for mount points.

      # It will be checked for updates each 60 seconds.

      # The format of the file is: /url=worker

      # /examples/*=loadbalancer

      JkMountFile conf/uriworkermap.properties

      # Add shared memory.

      # This directive is present with 1.2.10 and

      # later versions of mod_jk, and is needed for

      # for load balancing to work properly

      JkShmFile logs/jk.shm

      # Add jkstatus for managing runtime data

      <Location /jkstatus/>

      JkMount status

      Order deny,allow

      Deny from all

      Allow from 127.0.0.1

      </Location>

       

      6. The workers.properties in Apache server's conf directory is listed below:

       

      # Define list of workers that will be used

      # for mapping requests

      worker.list=loadbalancer,status

       

      # Define Node1

      # modify the host as your host IP or DNS name.

      # Nitin JBoss all node uses AJP port 8009

      worker.all.port=8009

      worker.all.host=localhost

      worker.all.type=ajp13

      worker.all.lbfactor=1

      worker.all.cachesize=10

       

      # Define Node2

      # modify the host as your host IP or DNS name.

      # Nitin JBoss node2 node uses AJP port 8109 which is 100 more than 8009

      worker.node2.port=8109

      worker.node2.host=localhost

      worker.node2.type=ajp13

      worker.node2.lbfactor=1

      worker.node2.cachesize=10

       

      # Load-balancing behaviour

      worker.loadbalancer.type=lb

      worker.loadbalancer.balance_workers=all,node2

       

      #Configure worker nodes in mod_jk

      worker.loadbalancer.sticky_session=1

      #worker.list=loadbalancer

      # Status worker for managing load balancer

      worker.status.type=status

       

      7. The uriworkermap.properties (in Apache server's conf directory) has been listed below:

       

      # Simple worker configuration file

      # Mount the Servlet context to the ajp13 worker

      # Created by Nitin with reference to JBoss CLustering guide

      /jmx-console=loadbalancer

      /jmx-console/*=loadbalancer

      /web-console=loadbalancer

      /web-console/*=loadbalancer

      /XCLUST=loadbalancer

      /XCLUST/*=loadbalancer

       

      8. I placed the XCLUST.war (my sample web-app) in the farm folder of all node (which is one of the participating folder in my cluster). When both the nodes were started the XCLUST.war was copied into the farm folder of node2 (the second node in my cluster). Also I checked both of the nodes recognized each other in the cluster. The server log at node all looked like:

       

      JBoss_5_1_0_GA date=200905221053)] Started in 1m:52s:719ms

      23:36:29,812 INFO  [NitCluster1] New cluster view for partition NitCluster1 (id:

      1, delta: 1) : [127.0.0.1:1099, 127.0.0.1:1199]

      23:36:29,937 INFO  [RPCManagerImpl] Received new cluster view: [127.0.0.1:2037|1

      ] [127.0.0.1:2037, 127.0.0.1:2107]

      23:36:29,953 INFO  [NitCluster1] I am (127.0.0.1:1099) received membershipChange

      d event:

      23:36:29,953 INFO  [NitCluster1] Dead members: 0 ([])

      23:36:29,953 INFO  [NitCluster1] New Members : 1 ([127.0.0.1:1199])

      23:36:29,953 INFO  [NitCluster1] All Members : 2 ([127.0.0.1:1099, 127.0.0.1:119

      9])

      23:36:43,796 INFO  [GroupMember] org.jboss.messaging.core.impl.postoffice.GroupM

      ember$ControlMembershipListener@1aff300 got new view [127.0.0.1:2037|1] [127.0.0

      .1:2037, 127.0.0.1:2107], old view is [127.0.0.1:2037|0] [127.0.0.1:2037]

      23:36:43,796 INFO  [GroupMember] I am (127.0.0.1:2037)

      23:36:43,796 INFO  [GroupMember] New Members : 1 ([127.0.0.1:2107])

      23:36:43,796 INFO  [GroupMember] All Members : 2 ([127.0.0.1:2037, 127.0.0.1:210

      7])

       

      9. In my simple web-app (named XCLUST) I am testing the following scenario to check JBoss Clustering/Failover:

        (a) User performs a login on login page.

        (b) User is taken to the index.jsp on successful login.

        (c) In index.jsp the username (retrieved from request-->Principal), user role (retrieved from request) are set in the user session using session.setAttribute() method. On index.jsp I also have a link to another JSP which will retrieve the session data being set in index.jsp.

        (d) All of the above steps (a), (b), (c) happens on either "all" node or "node2". Now I take the same node down which has handled the above requests. My failover understanding: if I am able to retrieve the session data (set in Step c) by clicking on the link of another JSP (the link is provided at index.jsp) which will show me the session data, then the JBoss clustering/failover has been successfully implemented.

       

      However, the Step (d) fails and I am taken back to the login page of the application which proves that session was not replicated across the other node.

      I've tried many things (hit and try) by reading various links available on internet but I wasn't able to get it right.

       

      Request you to let me know the mistake that I am doing here. I'll be delighted to share further information that you may need.

       

      Thank You,

      Nitin