Re: [Quickfix-developers] Incorrect handling of SequenceReset

[Brian E. <azz...@ya...>]

Oren -

That code was rearranged because otherwise we would timeout (heartbeat) while processing gap-fills/sequence resends. If you check the sequence number prior to incrementing the received time, the heartbeat timeout got triggered and the session would drop.

We'll have to be careful how to rearrange the code so we don't fix the new problem by reintroducing the old one.

I'm attaching the original email chain that caused us to create the existing code (Jun 27 2005 patch to Session.cpp).

- Brian

---- Original messages follow ----

Oren -

I believe the following change to Session.cpp will fix the timeout
problem when receiving out-of-sequence messages while awaiting a
sequence reset/gap-fill:

Move the following lines in Session::verify(...)

    UtcTimeStamp now;
    m_state.lastReceivedTime( now );

from their current position up to a spot just before the preceding
if/else clause:

-->>Place the code here<<--
if ( checkTooHigh && isTargetTooHigh( msgSeqNum ) )

This will increment the "lastReceivedTime" in the SessionState object
even when the sequence number is wrong. This appears to solve a whole
bunch of interrelated timeouts that could occur in this scenario (test
request, heartbeat, logon response, etc.) in one quick hit. Sequence
too low is largely unaffected by this change, as it will cause a
disconnect when hit, so that part of the code shouldn't need to be
rearranged.

It was somewhat unclear to me whether the following line:

    m_state.testRequest( 0 );

Also needed to be moved, but it seemed like it did not.

- Brian Erst
Thynk Software, Inc.
--- Oren Miller <or...@qu...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ:
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> Seems to me this shouldn't be happening.  I'm guessing that the
> engine isn't 
> processing the message because the sequence number is too high, hence
> no 
> heartbeat is processed.  I believe that out of sequence messages
> should 
> probably count as a keep-alive even if their contents arn't
> processed.
> 
> --oren
> 
> ----- Original Message ----- 
> From: "Alexey Zubko" <ale...@in...>
> To: <qui...@li...>
> Sent: Monday, June 27, 2005 1:44 PM
> Subject: [Quickfix-developers] MsgSeqNum too high problem
> 
> 
> > QuickFIX Documentation: 
> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX FAQ:
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> > Hi,
> >
> > I'd like to ask if QF initiator acts correctly in the following
> scenario.
> > The initiator detects that seqnum of a server is too high and sends
> a 
> > resend message.
> > The server doesn't resend requested messages, but there are
> heartbeat 
> > messages.
> > The initiator disconnects because of timeout on heartbeat. :-)
> > Below is the initiator's log.
> >
> > 20050627-17:52:50 : Created session
> > 20050627-17:52:51 : Connecting to eng-server on port 5725
> > 20050627-17:52:51 : Connection succeeded
> > 20050627-17:52:52 : Initiated logon request
> > 20050627-17:53:15 : Received logon response
> > 20050627-17:53:15 : MsgSeqNum too high, expecting  13 but received
> 15
> > 20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 14
> > 20050627-17:53:15 : MsgSeqNum too high, expecting  13 but received
> 16
> > 20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 15
> > 20050627-17:53:15 : MsgSeqNum too high, expecting  13 but received
> 17
> > 20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 16
> > 20050627-17:53:22 : Sent test request TEST
> > 20050627-17:53:22 : MsgSeqNum too high, expecting  13 but received
> 18
> > 20050627-17:53:22 : Sent ResendRequest FROM: 13 TO: 17
> > 20050627-17:53:37 : MsgSeqNum too high, expecting  13 but received
> 19
> > 20050627-17:53:37 : Sent ResendRequest FROM: 13 TO: 18
> > 20050627-17:53:40 : Timed out waiting for heartbeat
> > 20050627-17:53:40 : Disconnecting
> >
> >
> >
> > -- 
> >
> > Regards,
> > Alexey Zubko
> >
> > Infinium Capital Corporation
> > (416) 360-7000 ext. 305


----- Original Message ----
From: Oren Miller <or...@qu...>
To: Caleb Epstein <cal...@gm...>; Ajay Kamdar <Aja...@tr...>
Cc: qui...@li...
Sent: Saturday, April 29, 2006 6:18:38 PM
Subject: Re: [Quickfix-developers] Incorrect handling of SequenceReset

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

----- Original Message ----- 

In practice, the Session should eventually disconnect due to heartbeat
timeouts if the SequenceReset isn't processed properly.  Did you wait
long enough for this to happen in your tests?

-----------------------------

I don't think it would actually.  This is a snippet of the code for 
processing messages:

    UtcTimeStamp now;
    m_state.lastReceivedTime( now );
    m_state.testRequest( 0 );

    if ( checkTooHigh && isTargetTooHigh( msgSeqNum ) )
    {
      doTargetTooHigh( msg );
      return false;
    }
    else if ( checkTooLow && isTargetTooLow( msgSeqNum ) )
    {
      doTargetTooLow( msg );
      return false;
    }

Looks like the lastReceivedTime is being updated before we are even checking 
the sequence numbers.  So I don't believe a heartbeat timeout would ever 
occur.  Perhaps we should only update the received time if we actually 
process the message?

--oren



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers