Load-Balancing Policies for Clusters

A publisher sends JMS messages to a cluster based on the load-balancing policy you specify. You specify one of the following load-balancing policies for the cluster when you define the cluster connection factory:

Round Robin. A policy where the first publish operation is routed to the first Broker in the cluster connection, the second publish operation is routed to the second Broker, and so on until all Brokers are used. Then the sequence repeats itself. Use this policy if you want to equally distribute the publish operations across all the Brokers in the cluster.

Sticky. A policy where clients route all publish operations to the first Broker in the cluster connection. Only when the first Broker fails, the webMethods Broker Client API for JMS begins to route all publish operations to the next available Broker in the cluster. The publishing task will not be switched back from the second Broker to the first Broker even if the first Broker starts again unless the second Broker fails.

Random. A policy where publish operations are routed randomly to any Broker in the cluster. It is possible that one of the Brokers might receive too many messages to process, while the other servers are idle.

Weighted Round Robin. A policy where each Broker in the cluster handles a different message processing load. You can specify a "weight" to each Broker, which signifies how the Broker must share the message load relative to the other Brokers in the cluster. The weight determines how many more (or fewer) messages a Broker must receive, compared to the other Brokers in the cluster. You must carefully determine the relative weights to assign to each Broker.

If all Brokers in the cluster have the same weight, they will each share an equal proportion of the load.

If one Broker has weight 1 and all other Brokers have weight 2, the Broker with weight 1 will bear half of the load compared to the other Brokers.

If you have three Brokers in a cluster that must be governed by a weighted round robin policy, assign weight 4 for Broker 1, weight 12 for Broker 2, and weight 1 for Broker 3. In this example, for every 17 messages, Broker 1 gets 4 messages, Broker 2 gets 12 messages, and Broker 3 gets 1 message.

Multisend Guaranteed. A multisend policy where a client publishes a message to x out of y Brokers in a cluster by using XA transactions. Each Broker in the cluster acts as an individual XA resource and the publish operation is considered to be successful if the message is received by x out of y Brokers in the cluster. For example, if there are 10 Brokers in cluster and you want to guarantee publishing to two Brokers, then you use two out of 10 Brokers. Multisend guaranteed policy works only with the XA connection type.

The client must use the correct JMS APIs to retrieve the XA resources, enlist the resources with the transaction manager, and perform the XA operations. The JMS APIs do not automatically perform these transaction management operations.

For more information about preventing duplicate message delivery by the JMS API to the subscriber, see the "Message Pre-Acknowledgement" section in the webMethods Broker Messaging Programmer’s Guide.

Multisend Best Effort. A multisend policy where a client publishes a message to all Brokers, or as many Brokers as possible, in the cluster. The publish operation is considered successful if even one of the Brokers receives the message. The message that the client publishes to the Brokers is non-transactional in nature. Multisend best effort policy does not work with the XA connection type.