-
1. Re: Clustering - Messages are not pulled from one node to another
jms_j Sep 1, 2010 5:34 AM (in response to mallalli)I am confused with your post, since your subject says:"Messages are NOT pulled from one node to another", but the actual content of your message says otherwise when you said "The problem i am facing is messages are pulled between one node(ServerPeerID=1) to another(ServerPeerID=2) when one of the consumer is slow." ... so the messages ARE pulled.
Then you ask the question "How to achieve this load balancing at the consumer side when one consumer is taking long time to process a message, how pull the message from one node to another to balance this." ... but you just said in the previous sentence that IS what is happening.
In any case, I am replying with the same reply that I gave to Jeff Watkins earlier:
( See "Server Side Loadbalancing" section ):
http://community.jboss.org/wiki/JBMCluster
To quote:
{quote}This behaviour can sometimes cause confusion. The classic case is a user sets up a cluster of N nodes with a clustered queue, then sends messages to a single node and wonder why all their consumers on different nodes aren't processing the messages. This is because the local node still has spare cpu cycles so there is no point in allowing other nodes to consume, since that would involve unnecessary network round tripping. So it's actually the optimal use of resources.
{quote}
-
2. Re: Clustering - Messages are not pulled from one node to another
mallalli Sep 1, 2010 5:51 AM (in response to jms_j)I am sorry Jesus Salvo. I meant the messages are NOT pulled from one node to another. There was a typo in the previous post, i have changed it.
Thanks a lot.
-
3. Re: Clustering - Messages are not pulled from one node to another
jms_j Sep 1, 2010 9:28 PM (in response to mallalli)In that case, that link that I mentioned earlier shows that it is the default behaviour for JBM 1.4.x, in particular the text that I quoted above. Things may be different with HornetQ though that comes with JBAS 6.
What we did internally in our case was to create a producer to all nodes in the cluster, using the org.jboss.ha.framework.interfaces.HAMembershipListener interface to determine how many nodes there are in the cluster, then using a round-robin policy for the JMS connection factory, which would eventually create a producer for each node in the cluster.
Thus, when sending a message into a queue:
1) message A gets sent over producer 1 on node 1
2) message B gets sent over producer 2 on node 2
3) message C gets sent over producer 3 on node 3
4) message D gets sent over producer 1 on node 1
etc ...
Not very pretty, since really, the user of the JMS interfaces should NOT care how many nodes there are in the cluster, and should be completely agnostic if the JMS is clustered or not ... but ... this was the only way for us to reliably distribute the load over a JBM cluster.
For example, I did not have to do the above hack for iPlanet / SunOne / GlassFish MessageQueue.
Hopefully, HornetQ will be better so that I don't have to do the above hack with JBoss.