When using an asynchronous SessionProxy and an external cluster, if we detect a gap when receiving a Logon message, and the Logon message is immediately followed by a ResendRequest (i.e. the other party also detected a gap), then we want to make sure that we process the received ResendRequest only after we effectively sent our own.
It is not currently possible, and as a consequence the replayer on engine side can send a SequenceReset/GapFill faster than the ResendRequest. This generates a "MsgSeqNum too low" error on the other side.
This PR allows to use SessionProxy to indicate that the ResendRequest processing must be delayed, so the Session will not do anything. When the SessionProxy is ready, it can asynchronously trigger the processing of the ResendRequest.
See issue #503
When using an asynchronous SessionProxy and an external cluster, if we detect a gap when receiving a Logon message, and the Logon message is immediately followed by a ResendRequest (i.e. the other party also detected a gap), then we want to make sure that we process the received ResendRequest only after we effectively sent our own.
It is not currently possible, and as a consequence the replayer on engine side can send a SequenceReset/GapFill faster than the ResendRequest. This generates a "MsgSeqNum too low" error on the other side.
This PR allows to use SessionProxy to indicate that the ResendRequest processing must be delayed, so the Session will not do anything. When the SessionProxy is ready, it can asynchronously trigger the processing of the ResendRequest.