JBoss Messaging connections factories can optionally support load balancing and automatic failover. This is determined by the attributes on supportsLoadBalancing and supportsFailover on the connection factory.

See the section Section 7.6.4, “Configuring Connection Factories” for more information.

When a message is sent to a queue on particular node of the cluster, the system must decide whether the current node will handle it or whether it should send it to another node to handle.

The same applies if there are shared durable subscriptions on a topic and the message is being sent to a topic

The correct decision to make depends on your application topology.

If your application consists of a set of servers with the same MDBs deployed on each server, and you have many well distributed producers sending messages on all the nodes of the cluster, then the best policy is to always favour the local queue, since extra network trips are more expensive and the other nodes are also havng local messages sent to them

However if your application consists of a set of homogenous MDBs but you have few or badly distributed producers, then always favouring the local producer will mean the other nodes are being starved of messages and not using their CPUs cycles efficiently for messaging processing.

In this case, a good policy is to use a round robin routing policy where messages are round robin distributed to different nodes as they arrive.

In general, use the DefaultRoutingPolicy (this always favours the local queue) if you have many well distributed producers, and use the RoundRobinRoutingPolicy if you have few or badly distributed producers.

This are specified in the clustered post office config, by specifying the following attribute

To favour the local queue:

       <attribute name="ClusterRouterFactory">org.jboss.messaging.core.plugin.postoffice.cluster.DefaultRouterFactory</attribute>
      

To round robin:

         <attribute name="ClusterRouterFactory">org.jboss.messaging.core.plugin.postoffice.cluster.RoundRobinRouterFactory</attribute>
      

Once messages have arrived on queues in a cluster, in an ideal world they will all be consumed at the same rate, and there will be consumers on each node.

However, in some application topologies, consumes may close on queues on a node, leaving messages otherwise stranded, or perhaps consumers on some nodes are fast than consumers on other nodes causing messages to build up on one node or another and adversely effecting latency.

JBoss Messaging allows messages to pulled from one node to another as load dictates in order to cope with such situations

Whether or not you should activate message pulling (message redistribution) depends on your application topology

For an application that consists of a set of servers with a heterogenous bank of MDBs (or other consumers) deployed on each node, consuming at approximately the same rate, then message redistribution is not necessary.

However, if your application consists of different numbers or rates of consumers on different nodes then message redistribution may help

In general, use message redistribution when your consumers are not well distributed across the cluster or if they have greatly varying rates.

Message redistribution is set by setting the following attribute in the clustered post office configuration:

For no message redistribution:

           <attribute name="MessagePullPolicy">org.jboss.messaging.core.plugin.postoffice.cluster.NullMessagePullPolicy</attribute>
      

For message redistribution:

           <attribute name="MessagePullPolicy">org.jboss.messaging.core.plugin.postoffice.cluster.DefaultMessagePullPolicy</attribute>
      

When selecting message redistribution you should also choose a value of StatsSendPeriod appropriately.