Re: [Quickfix-developers] Already sent ResendRequest ... Not sending another.

[Caleb E. <cal...@gm...>]

On 1/2/06, Scott Harrington <sco...@fo...> wrote:

> Has anyone encountered problems with the code that was added between 1.9.=
4
> and 1.10.2 that emits the "Not sending another" message?  Oren's CVS
> comment was "fix for stack over flow with recursive next calls. Do not
> resend if request already exists with same range.  Submitted by Caleb
> Epstein."  Note that I'm using QuickFIX/J, but the C++ code is the same.
>
> My session started out normally, but (possibly due to an unrelated bug in
> QFJ socket input) somehow loses a message (#216250) and should have tried
> to get the counterparty to resend it.  But due to an earlier (successful)
> ResendRequest, the "Not sending another" code kicks in repeatedly (a very
> bad failure mode -- app gets no new messages yet session appears
> functional).
>
> I see two fixes:
> (1) modify nextSequenceReset() to call state.setResendRange(0,0)


This method is for handling incoming SeqneceReset messages, so this would
not be the right place to fix this.

(2) modify the range check in doTargetTooHigh()


The range check is correct, its just that the data in m_state.resendRange i=
s
not.  The right fix I believe is to modify the code in
Session::generateResendRequest to track the actual upper bound of the range
it has requested, instead of the number 0 or 9999999 depending on FIX
version.  Its a one-line change that I've just committed.

Any advice?  See my events below.  The message length error was emitted by
> quickfix.netty.FIXMessageData.read().
>
> 20051230-13:19:50: Created session
> 20051230-13:19:50: connection established:
> net.gleamynode.netty2.Session@191f801
> 20051230-13:19:54: Initiated logon request
> 20051230-13:19:54: Received logon response
> 20051230-13:19:54: MsgSeqNum too high, expecting 197648 but received
> 197650
> 20051230-13:19:55: Sent ResendRequest FROM: 197648 TO: 0
> 20051230-13:19:55: Received SequenceReset FROM: 197648 TO: 197651
> 2005-12-30 16:07:09,050 Error in message length
> 20051230-16:07:09: MsgSeqNum too high, expecting 216250 but received
> 216251
> 20051230-16:07:09: Already sent ResendRequest FROM: 197648 TO: 0.  Not
> sending another.


This is definitely a problem.  The way the "Already sent ResendRequest ...
not sending another" logic is supposed to work is that when a "MsgSeqNum to=
o
high" condition is detected, QuickFIX sends one and only one ResendRequest
to satisfy the range of messages that were missed.  The message that
triggered this ResendRequest is placed on an internal queue of messages for
later processing.  Once a message is successfully processed from this
internal queue, the original ResendRequest is considered to have been
satisifed and the "Already sent ResendRequest" flag should be cleared.  You
should see a message in the log like "Processed QUEUED message: #" when thi=
s
happens, but that didn't happen here, which is something I've not
encountered before.  It suggests that there is a way to bypass the
"nextQueued" logic in the Session which should probably not be happening.

--
Caleb Epstein
caleb dot epstein at gmail dot com