JBoss 3.2.3 - Clustered MBeans.

[slbain]

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 archive to the cluster.

My service is an mbean extending HAServiceMBeanSupport. It uses a ProxyFactoryHA instance and a JRMPInvokerHA invoker. 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 the service is invoked e.g. 1000 times The bulk are consistently invoked on the one node - which happens to be the node running the client for-loop code. However I only ever see 1 or 2 of those invocations being invoked on 'the other' node.

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

Can anyone help or suggest where I may be going wrong ?

Thanks for all and any help.
sinclair

[adrian.brock]

Do you see the same thing with RandomRobin?
If you do, you have a pattern in your invocations.

[slbain]

Adrian,
Cheers for the reply!

I have been debugging the problem and so far it looks as if the FamilyClusterInfo list initially has two targets - JRMPInvokerProxy_Stubs to the respective endpoints - however after an invocation to the less-favoured node the list is reduced to a single target ie. the favoured node.

Under what circumstances does the list get updated and more specifically how is the determination to remove a target made ?

P.S. I had a limited success and did see the load-balancing behave as expected however this is no longer the case ... today. ;-)

Thanks for any pointers !!
sinclair

[adrian.brock]

Any changed view is returned to the client after the invocation.
Take a look on the cluster partition mbean on the jmx-console.
You'll find what it thinks is in the cluster and a history view.

[slbain]

Adrian,

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

[adrian.brock]

Ask your question in the clustering forum.

What I can tell you is that jboss clustering is an abstraction, it is possible
to swap out jgroups for a different group communication library.