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.

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.

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.