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

[Oren M. <or...@qu...>]

I'm looking at SessionState::resendRequested, and see the following logic...

 bool resendRequested() const
  { return !(m_resendRange.first == 0 && m_resendRange.second == 0); }

Wouldn't this erroneously return false in the case where a resend 
request to INFINITY (defined as 0 in FIX.4.2. and later) is being 
processed?  Shouldn't this just be { return m_resendRange.first != 0; } ?

--oren

Caleb Epstein wrote:

> On 1/2/06, *Scott Harrington* <sco...@fo... 
> <mailto: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 is 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 too 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 this 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