I think you're misunderstanding how clustering works.

Let me give an overview again. This has also been covered on (many) other 
threads

If you use a connection factory with load balancing = true to *create* a 
connection to the cluster then subsequent create connection attempts will 
connect to different nodes in the cluster in a round robin fashion.

So connection 1 on node 2, connection 2 on node 3, connection 3 on node 1, 
connection 4 on node 2 etc. The first node is chosen randomly.

When you use one of those connections to *send* messages then all the messages 
sent by that connection will go to the node that connection is connected to. 
Different messages sent *do not* get sent to different nodes. That would be 
extremely hard to do and still maintain transactional semantics without being 
*extremely* slow.

Ok, that's for sending messages, how about consuming messages?

If you create a connection, this time to *consume* messages using a connection 
factory with load balancing = true, then, again, subsequent connection are 
created to different nodes of the cluster in a round robin fashion.

So if you deployed, say, 3 different MDBs on node A with a connection factory 
with load balancing = true, then they would actually be connected to and 
consuming from *different nodes of the cluster*.

For an MDB installation this is typically not what you want. With MDBs you 
normally deploy the same set of MDBs on each node of the cluster.

So node A, B, and C all have the same set of MDBs. In this scenario it makes no 
sense for the MDBs one node A to actually be consuming from the nodes B and C. 
It is far more efficient for the MDBs on node A to be only consuming from node 
A, the MDBs on node B to be consuming from node B etc. 

As long as you have a good distribution of connections *sending* messages 
across the cluster, then this is the optimal configuration. You're not wasting 
network bandwidth moving messages between nodes when there's a consumer on the 
local node that could quite happily consume the message.

Now, JBM goes one step further. It has something called "message distribution".

Consider the case where consumers on node A are slower than consumers on node 
B. In that case it may make sense to move messages from A to B in order to 
utilise the cluster effectively.

JBM does this automatically. It will transparently shift messages from a queue 
on node A to a queue on node B according to load. You don't need to connect to 
the other node directly to do this. Just connect to the local node, JBM does 
the rest.

I hope that helps clear up the confusion.

As I say, there have been lots of other threads like this in the past - it's 
worth taking a look.

View the original post : 
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4158654#4158654

Reply to the post : 
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4158654
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user

Reply via email to