Broker 10.5 | webMethods Broker Documentation | webMethods Broker Messaging Programmer's Guide | JMS Policy Based Client-Side Clustering | What is Client-Side Clustering for JMS Client Applications? | Distributing Message Volume (Load Balancing)
Distributing Message Volume (Load Balancing)
By distributing the message flow across several Brokers, the messaging system becomes less vulnerable to bottlenecks caused by factors such as a high rate of messages from a publisher, or by a single Broker processing the messages at too slow a rate, which would cause excessive message queuing.
The following figure shows, in a generic sense, how JMS messages flow from a publishing application to subscribing applications through a Broker cluster. The figure uses a simplified messaging scenario consisting of one publishing application, one destination, and two subscribing applications.
As shown in the figure:
*The webMethods API for JMS on the publisher side use the asynchronous publishing interface for initiating multiple publishing operations concurrently to all the available Brokers in the cluster.
*During a publish operation, the webMethods API for JMS determines the Broker to which a published message is routed. The load balancing policy configured in the cluster connection factory defines the routing of the published messages to the Brokers in the cluster.
*A subscriber is connected to all the Brokers in the cluster as shown in the figure and will receive a message from any Broker in the cluster.
Subscriber applications connect to all the Brokers in a cluster, receiving messages from the queues. Messages at the subscriber end are not distributed according to a load balancing policy, as they are at the publisher end. Rather, the messages are simply aggregated from the individual message threads on each clustered Broker and retrieved on a first-come-first-serve basis. The messages are not received by the subscribers in any guaranteed order.
You will need to add custom code to your applications to maintain order of message delivery.