Broker 10.5 | webMethods Broker Documentation | webMethods Broker Messaging Programmer's Guide | JMS Policy Based Client-Side Clustering | Cluster Load Balancing Policies | Message Pre-Acknowledgement | Example
 
Example
For example, consider a cluster is governed by multisend guaranteed policy. The cluster has four Brokers: Broker 1, Broker 2, Broker 3, and Broker 4. Broker 1 is the primary Broker. Only Broker 1, Broker 2, and Broker 3 are used to publish the messages. The pre-acknowledgement parameters have the following settings:
For Broker 1, pre-acknowledgement-timer-interval=10, tentative-pre-acknowledgement-timeout=20, and confirmed-pre-acknowledgement-timeout=7200.
For Broker 2, pre-acknowledgement-timer-interval=5, tentative-pre-acknowledgement-timeout=30, and confirmed-pre-acknowledgement-timeout=7200.
For Broker 3, pre-acknowledgement-timer-interval=5, tentative-pre-acknowledgement-timeout=40, and confirmed-pre-acknowledgement-timeout=7200.
The webMethods API for JMS performs the following steps:
1. The webMethods API for JMS sends the published message to all the Brokers in the cluster.
2. The subscriber receives the message from the primary Broker, Broker 1, and acknowledges receiving the message.
3. The Broker 2, and Broker 3 will hold the published message until it receives the pre-acknowledgement message from the subscriber.
a. Broker 2 will hold the message for the time period specified by the tentative-pre-acknowledgement-timeout parameter, that is 30 seconds. At every time interval specified by the pre-acknowledgement-timer-interval parameter, that is 5 seconds, the Broker 2 will update the timer status for the message. Broker will perform this step every 5 seconds until the message is not removed from the queue.
b. Broker 3 will hold the message for the time period specified by the tentative-pre-acknowledgement-timeout parameter, that is 40 seconds. At every time interval specified by the pre-acknowledgement-timer-interval parameter, that is 5 seconds, the Broker 3 will update the timer status for the message. Broker will perform this step every 5 seconds until the message is not removed from the queue.
4. The webMethods API for JMS sends an acknowledgement to all the Brokers in the cluster.
5. If the other Brokers in the cluster receive the pre-acknowledgement message from the webMethods API for JMS before the specified message pre-acknowledgement timeout interval, these Brokers remove the published document from its queue.
6. If the Brokers in the cluster do not receive the message pre-acknowledgement before the message pre-acknowledgement timeout interval, the other Brokers in the cluster will forward the published message to the subscriber.
a. If Broker 2 does not receive the pre-acknowledge message before 30 seconds, it will send the message to the subscriber.
b. If Broker 3 does not receive the pre-acknowledge message before 40 seconds, it will send the message to the subscriber. For more information about recommended pre-acknowledgement setting, see Message Pre-Acknowledgement Time Interval Setting.
7. The webMethods API for JMS will never publish the message to Broker 4. But, Broker 4 also receives a confirmed pre-acknowledgement from the webMethods API for JMS. Broker 4 deletes the confirmed pre-acknowledgement after the confirmed-pre-acknowledgement-timeout interval, that is after 7200 seconds in this example.