Building Your Event-Driven Architecture : Using Integration Server to Build a Client for JMS : Exactly-Once Processing for JMS Triggers : Delivery Count for JMS Messages
Delivery Count for JMS Messages
The delivery count indicates the number of times the JMS provider has delivered or attempted to deliver a message to the JMS trigger. Most JMS providers track the message delivery count in the JMS-defined property JMSXDeliveryCount. The initial delivery is 1, the second delivery is 2, and so on. A delivery count other than 1 indicates that the trigger might have received and processed (or partially processed) the message before.
For example, when Integration Server first retrieves a message for a JMS trigger, the JMSXDeliveryCount count is 1 (one). If a resource (JMS provider or Integration Server) shuts down before the trigger processes and acknowledges the message, Integration Server retrieves the message again when the connection is re-established. The second time Integration Server retrieves the message, the JMSXDeliveryCount is 2. A delivery count greater than 1 indicates that the JMS provider may have delivered the message to the trigger before.
The following table identifies the possible delivery count values and the message status associated with each value.
A delivery count of...
Indicates...
-1
The JMS provider that delivered the message does not maintain a JMSXDeliveryCount or an error occurred when retrieving the JMSXDeliveryCount. As a result, the delivery count is undefined. Integration Server uses a value of -1 to indicate that the delivery count is absent.
If other methods of duplicate detection are configured for this trigger (document history database or document resolver service), Integration Server uses these methods to determine the message status. If no other methods of duplicate detection are configured, Integration Server assigns the message a status of New and executes the trigger service.
1
This is the first time the JMS trigger received the message.
If the JMS trigger uses a document history to perform duplicate detection, Integration Server checks the document history database to determine the message status. If no other methods of duplicate detection are configured, Integration Server assigns the message a status of New and executes the trigger service.
>1
The JMS provider has delivered the message more than once. The trigger might or might not have processed the message before. The delivery count does not provide enough information to determine whether the trigger processed the message before.
If other methods of duplicate detection are configured for this trigger (document history database or document resolver service), Integration Server uses these methods to determine the message status. If no other methods of duplicate detection are configured, Integration Server assigns the message a status of In Doubt and acknowledges the message.
Integration Server uses delivery count to determine message status whenever you enable exactly-once processing for a JMS trigger. That is, setting the Detect duplicates property to true indicates delivery count will be used as part of duplicate detection.
Note:  
webMethods messaging triggers use a redelivery count instead of a delivery count for exactly-once processing.
Copyright © 2016 - 2016 Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback