This page describes the possible resend scenarios in Drop Copy message processing.

Drop Copy 4.0 will send messages with tag 97-PossResend=Y in the following scenarios:

1. While resending outbound messages that may have been in-flight during a single Drop Copy failover

2. While receiving outbound messages that may have been in-flight during iLink failover

3. While recovering unsent messages after a dual failure or before Sunday startup
   
   

Handling a Drop Copy Message with tag 97-PossResend=Y

Scenarios 1 & 2

All Execution Reports and Reject messages (except business rejects) from the source iLink session contain tag 5979-RequestTime, indicating the time each message was available for matching (aka FIFO time).

For messages from a given market segment, this timestamp increases sequentially on successive messages, except under certain conditions in which consecutive messages may have the same time.

When a Drop Copy target session receives a message with tag 97-PossResend=Y, indicating a possible resend, the client system must check tag 5979-RequestTime of the corresponding source session message to identify if the message was previously processed.

Resend messages generated in scenarios #1 and #2 can be identified as duplicates and ignored based on the comparison of the timestamp in tag 5979-RequestTime with the previously processed timestamp.

In the case where tag 5979-RequestTime of the possible Resend message contains the same value as the previously processed message, the client system must also compare the sequence number of the corresponding source session message to verify if the message was previously processed.

Scenario 3

Scenario #3 requires enhanced handling; in addition to ignoring messages having non-sequential timestamps, the Drop Copy instance will be recovering after a dual failover. The instance can send real-time messages interleaved with messages missed during the outage. The recovered messages will contain tag 97-PossResend=Y.

• For the dual failure or before Sunday startup scenarios, the Drop Copy target sessions may have to process an Execution Report - Order Modify or Execution Report - Order Cancel for a non-existing order (the acknowledgment for which can be pending recovery) and drop the respective Execution Report - Order Creation when received later (with tag 97-PossResend=Y).

• Additionally, the target session may receive an Execution Report - Fill on an order, in which the cumulative filled quantity (tag 14-CumQty) does not match the expected value, since Drop Copy has not yet recovered the remaining Execution Report - Fill messages. In this case, the client system should use the cumulative filled quantity from the current message as the total filled quantity, and ignore recovered messages received later with tag 97-PossResend=Y.