Broker 10.5 | webMethods Broker Documentation | webMethods Broker Messaging Programmer's Guide | JMS Policy Based Client-Side Clustering | Cluster Load Balancing Policies
 
Cluster Load Balancing Policies
 
How Does the Round Robin Cluster Policy Work?
How Does the Sticky Policy Work?
How Does the Multisend Best Effort Policy Work?
How Does the Multisend Guaranteed Policy Work?
Message Pre-Acknowledgement
JMS messages are published to the specific Brokers in a cluster based on the specified load balancing policy. Select one of the following load balancing policies for the cluster when you define the cluster connection factory.
Note:
The failover mechanism for each of these policies is as explained in Failover Mechanism in Clusters.
*Round Robin. A policy where the first publish operation is routed to the first Broker in the cluster, the second publish operation is routed to the second Broker and so on until all Brokers are used. Then the sequence repeats itself. You 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. Only when the first Broker fails, the webMethods API for JMS begins to route all publish operations to the next available Broker in the cluster.
*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 Brokers 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.
The following examples will help you better understand the weighted round robin policy:
*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 Broker 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, the webMethods API for JMS routes 4 messages to Broker 1, 12 messages to Broker 2, and 1 message to Broker 3.
*Multisend Best Effort. A multisend policy where a client publishes a message to all, 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 XA connection factory.
For more information about preventing duplicate message delivery by the webMethods API for JMS to the subscriber, see Message Pre-Acknowledgement.
*Multisend Guaranteed. A multisend policy where a client publishes a message to n out of m 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 n out of m Brokers in the cluster. For example, if there are 10 Broker in cluster, you want to guaranty publishing to 2 Brokers, then you use 2 out of 10 Brokers. Multisend guaranteed policy works only with XA connection type.
The client must use the correct webMethods APIs for JMS to retrieve the XA resources, enlist the resources with the transaction manager, and perform the XA operations. The webMethods APIs for JMS do not automatically perform these transaction management operations.
For more information about preventing duplicate message delivery by the webMethods API for JMS to the subscriber, see Message Pre-Acknowledgement.