如何请求重播已收到的修复消息

Question

I have an application that could potentitally throw an error on receiving a ExecutionReport (35=8) message. This error is thrown at the application level and not at the fix engine level. The fix engine records the message as seen and therefore will not send a ResendRequest (35=2). However the application has not processed it and I would like to manually trigger a re-processing of the missed ExecutionReport.

Forcing a ResendRequest (35=2) does not work as it requires modifying the expected next sequence number.

I was wonderin if FIX supports replaying of messages but without requiring a sequence number reset?

Answer 1

When processing an execution report, you should not throw any exceptions and expect FIX library to handle it. You either process the report or you have a system failure (ie call abort() ). Therefore, if your code that handles execution report throws an exception and you know how to handle it, then catch it in that very same function, eliminate the cause of the problem and try processing again. For example (pseudo-code):

// This function is called by FIX library. No exceptions must be thrown because
// FIX library has no idea what to do with them.
void on_exec_report(const fix::msg &msg)
{
    for (;;) {
        try {
            // Handle the execution report however you want.
            handle_exec_report(msg);
        } catch(const try_again_exception &) {
            // Oh, some resource was temporarily unavailable? Try again!
            continue;
        } catch(const std::exception &) {
            // This should never happen, but it did. Call 911.
            abort();
        }
    }
}

Of course, it is possible to make FIX library do a re-transmission request and pass you that message again if exception was thrown. However, it does not make any sense at all because what is the point of asking the sender (over the network, using TCP/IP) to re-send a message that you already have (up your stack :)) and just need to process. Even if it did, what's the guarantee it won't happen again? Re-transmission in this case is not only doesn't sound right logically, the other side (ie exchange) may call you up and ask to stop doing this crap because you put too much load on their server with unnecessary re-transmit (because IRL TCP/IP does not lose messages and FIX sequence sync process happens only when connecting, unless of course some non-reliable transport is used, which is theoretically possible but doesn't happen in practice).

When aborting, however, it is FIX library`s responsibility not to increment RX sequence unless it knows for sure that user has processed the message. So that next time application starts, it actually performs synchronization and receives missing messages. If QuickFIX is not doing it, then you need to either fix this, take care of this manually (ie go screw with the file where it stores RX/TX sequence numbers), or use some other library that handles this correctly.

Answer 2

This is the wrong thing to do.

A ResendRequest tells the other side that there was some transmission error. In your case, there wasn't, so you shouldn't do that. You're misusing the protocol to cover your app's mistakes. This is wrong. (Also, as Vlad Lazarenko points out in his answer , if they did resend it, what's to say you won't have the error again?)

If an error occurs in your message handler, then that's your problem, and you need to find it and fix it, or alternately you need to catch your own exception and handle it accordingly.

(Based on past questions, I bet you are storing ExecutionReports to a DB store or something, and you want to use Resends to compensate for DB storage exceptions. Bad idea. You need to come up with your own redundancy solution.)