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.
