1 Reply Latest reply on May 14, 2004 11:16 AM by sinclair bain

    JBoss 3.2.2 - Round-Robin load balancing.

    sinclair bain Newbie

      Hi there,

      I am trying to implement a load balancing prototype using the 'round-
      robin' policy <org.jboss.ha.framework.interfaces.RoundRobin>.

      I have a two node cluster set-up and communicating. I use the farm service to deploy the prototype to the cluster nodes.

      My service is an mbean using HA service support plus the dd is based upon:
      http://cvs.sourceforge.net/viewcvs.py/jboss/jbosstest/src/resources/jmx/ha/META-INF/jboss-service.xml?rev=1.2&view=auto

      In a client for-loop I invoke my service interface e.g. 1000 times however I only see 1 or 2 of those invocations being invoked on 'the other' node. The bulk are consistently invoked on the one node - which happens to be the node running the client for-loop code.

      My expectation was a more even distribution of these invocations between the two nodes. However this is not the case.

      Can anyone help or point to a config setting which I missed ?

      n.b. I am using jboss 3.2.3.

      Thank you for all and any help.
      sinclair

        • 1. Re: JBoss 3.2.2 - Round-Robin load balancing.
          sinclair bain Newbie

          Hi,
          This thread has been running on the JMX Forum:
          http://www.jboss.org/index.html?module=bb&op=viewtopic&t=49615
          This is the more appropriate forum.

          I traced my problem down to the smart-proxy having its list of targets updated on the return from the invocation.

          I got down to the JRMPInvokerHA.invoke() method where the HARMIResponse is constructed. There is a comparison between the from the Invocation instance and the <HATarget.clusterViewId> and these are not equal so the change is triggered.

          Now I looked into the JGroups/HAPartitionImpl interactions at the JGroups interface to try to understand how the HATarget gets its value set. I noticed the these 'low-level' view ids are not the same as the values displayed in the jmx-console 'DefaultPartition' mbean 'view id'. The high-level values are consistent across the cluster nodes. Some sequentially incremented value.

          I have traced through the DitributeReplicantManagerImpl.purgeDeadMembers() and calculateReplicantHash() but can see no relation to the high-level clustered view id.

          Why is the high-level view id not propogated down to this lower-level ? i.e. associate the 'replicants' directly with the cluster-wide view id.

          Thanks for your help!
          sinclair