Integration Server 10.3 | JMS Client Development Guide | Exactly-Once Processing for JMS Triggers | Extenuating Circumstances for Exactly-Once Processing | Circumstances in which Duplicate Messages Can Be Processed
 
Circumstances in which Duplicate Messages Can Be Processed
In the following situations, a trigger with exactly-once processing configured might process a duplicate message (document).
*If the client sends a message twice and assigns a different UUID each time, Integration Server does not detect the second message as a duplicate. Because the messages have different UUIDs, Integration Server processes both messages.
*If the document resolver service incorrectly determines the status of a message to be new (when it is, in fact, a duplicate), Integration Server processes the message a second time.
*If a client sends a message twice, and the second message is sent after Integration Server removes the expired message UUID entries from the document history table, Integration Server determines the second message is new and processes it. Because the second message arrives after the first message’s entries have been removed from the document history database, Integration Server does not detect the second message as a duplicate.
*If the time drift between the computers hosting a cluster of Integration Servers is greater than the duplicate detection window for the trigger, one of the Integration Servers in the cluster might process a duplicate message. (The size of the duplicate detection window is determined by the History time to live property under Exactly Once.)
For example, suppose the duplicate detection window is 15 minutes and that the clock on the computer hosting one Integration Server in the cluster is 20 minutes ahead of the clocks on the computers hosting the other Integration Servers. A trigger on one of the Integration Servers with a slower clock processes a message successfully at 10:00 GMT.
The Integration Server adds two entries to the document history database. Both entries use the same time stamp and both entries expire at 10:15 GMT. However, the Integration Server with the faster clock is 20 minutes ahead of the others and might reap the entries from the document history database before one of the other Integration Servers in the cluster does.
If the Integration Server with the faster clock removes the entries before 15 minutes have elapsed and a duplicate of the message arrives, the Integration Servers in the cluster will treat the message as a new message.
Note:
Time drift occurs when the computers that host the clustered servers gradually develop different date/time values. Even if the administrator synchronizes the computer date/time when configuring the cluster, the time maintained by each computer can gradually differ as time passes. To alleviate time drift, synchronize the cluster node times regularly.