Tune the Client's Subscription Message Tracking Timeout
If the client pool’s
subscription-message-tracking-timeout is set too low, your client will discard tracking records for live threads, increasing the likelihood of processing duplicate events from those threads.
This setting is especially important in systems where it is vital to avoid or greatly minimize duplicate events. If you detect that duplicate messages are being processed by your clients, increasing the timeout may help. Setting
subscription-message-tracking-timeout may not completely eliminate duplicate entries, but careful configuration can help minimize occurrences.
Duplicates are monitored by keeping track of message sequence IDs from the source thread where the operation originated. For a long-running system, you would not want to track this information for very long periods or the information may be kept long enough for a thread ID to be recycled. If this happens, messages from a new thread may be discarded mistakenly as duplicates of messages from an old thread with the same ID. In addition, maintaining this tracking information for old threads uses memory that might be freed up for other things.
To minimize duplicates and reduce the size of the message tracking list, set your client
subscription-message-tracking-timeout higher than double the sum of these times:
- The longest time your originating threads might wait between operations
- For redundant servers add:
- The server’s
- Total time required for failover (usually 7-10 seconds, including the time to detect failure)
- The server’s
You risk losing live thread tracking records if you set the value lower than this. This could result in your client processing duplicate event messages into its cache for the associated threads. It is worth working to set the
subscription-message-tracking-timeout as low as you reasonably can.
<!-- Set the tracking timeout to 70 seconds --> <pool name="client" subscription-enabled="true" subscription-message-tracking-timeout="70000"> ... </pool>