|Configuring Client/Server Event Messaging / Tuning Client/Server Event Messaging|
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.
<!-- Set the tracking timeout to 70 seconds --> <pool name="client" subscription-enabled="true" subscription-message-tracking-timeout="70000"> ... </pool>