quickfix - How to request a replay of an already received fix message -

i have application potentitally throw error on receiving executionreport (35=8) message. error thrown @ application level , not @ fix engine level. fix engine records message seen , therefore not send resendrequest (35=2). application has not processed , manually trigger re-processing of missed executionreport.

forcing resendrequest (35=2) not work requires modifying expected next sequence number.

i wonderin if fix supports replaying of messages without requiring sequence number reset?

when processing execution report, should not throw exceptions , expect fix library handle it. either process report or have system failure (i.e. call abort()). therefore, if code handles execution report throws exception , know how handle it, catch in same function, eliminate cause of problem , try processing again. example (pseudo-code):

// function called fix library. no exceptions must thrown because // fix library has no idea them. void on_exec_report(const fix::msg &msg) {     (;;) {         try {             // handle execution report want.             handle_exec_report(msg);         } catch(const try_again_exception &) {             // oh, resource temporarily unavailable? try again!             continue;         } catch(const std::exception &) {             // should never happen, did. call 911.             abort();         }     } } 

of course, possible make fix library re-transmission request , pass message again if exception thrown. however, not make sense @ because point of asking sender (over network, using tcp/ip) re-send message have (up stack :)) , need process. if did, what's guarantee won't happen again? re-transmission in case not doesn't sound right logically, other side (i.e. exchange) may call , ask stop doing crap because put load on server unnecessary re-transmit (because irl tcp/ip not lose messages , fix sequence sync process happens when connecting, unless of course non-reliable transport used, theoretically possible doesn't happen in practice).

when aborting, however, fix library`s responsibility not increment rx sequence unless knows sure user has processed message. next time application starts, performs synchronization , receives missing messages. if quickfix not doing it, need either fix this, take care of manually (i.e. go screw file stores rx/tx sequence numbers), or use other library handles correctly.