Broker 10.15 | webMethods Broker Documentation | webMethods Broker Messaging Programmer's Guide | JMS Policy Based Client-Side Clustering | Cluster Load Balancing Policies | Message Pre-Acknowledgement
 
Message Pre-Acknowledgement
 
Message Pre-Acknowledgement Time Interval Setting
Example
The published message is sent to multiple Brokers in the cluster if the cluster is governed by either multisend guaranteed or multisend best effort policy. You require a mechanism to prevent duplicate message delivery to the subscriber. The message pre-acknowledgement functionality prevents duplicate message delivery.
In a cluster configured with either multisend guaranteed or multisend best effort policy, the publisher’s webMethods API for JMS marks one of the Brokers in the cluster as the primary Broker. The webMethods API for JMS performs the following steps to prevent duplicate delivery of messages and ensure that the subscriber has received at least one copy of the message.
1. The webMethods API for JMS sends the published message to multiple Brokers in the cluster based on the policy setting. In case a cluster is configured with multisend guaranteed policy, the webMethods API for JMS sends the message to m out of n Brokers in the cluster. One of the Brokers in the cluster marked as the primary Broker receives the published message. The other Brokers participating in the message distribution in the cluster receive a tentatively pre-acknowledged message.
2. The primary Broker sends the message to the subscriber. The remaining Brokers in the cluster will hold the published message until they receive the confirmed pre-acknowledgement for the message from the subscriber’s webMethods API for JMS.
3. The subscriber receives the message from the primary Broker and acknowledges receiving the message.
4. For every message acknowledgement from the subscriber client, the webMethods API for JMS sends:
a. an acknowledgement to the primary Broker in the cluster. The primary Broker deletes the message from the client queue.
b. a confirmed pre-acknowledgement to the other Brokers in the cluster. The secondary Brokers delete the tentatively pre-acknowledged messages from the client queues.
5. If any of the Brokers in the cluster does not receive the message pre-acknowledgement before the message pre-acknowledgement timeout interval, that Broker will forward the published message to the subscriber.