Do you see the same thing with RandomRobin?
If you do, you have a pattern in your invocations.
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 !!
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.
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!
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.