Re: [Quickfix-developers] bug in Session.cpp, and more.

[Scott K. <sc...@la...>]

FYI, have submitted bug reports:

UseLocalTime=Y does not work
https://sourceforge.net/tracker/?func=detail&atid=1126912&aid=3023908&group_id=37535

MsgSeqNum not incremented for received ResendRequest message
https://sourceforge.net/tracker/?func=detail&atid=1126912&aid=3023896&group_id=37535

On Wed, Jun 30, 2010 at 5:28 PM, Scott Kathrein
<sc...@la...>wrote:

> See end for my main question here.
>
>
> I think I found a bug in how the ResendRequest messages are handled. Please
> correct me if I'm doing something wrong here as it's hard for me to believe
> this version of quickfix is so buggy. I'm using the latest version 1.13.3
>
> This one's a bit more complicated than the extra const's in
> MessageCracker.h...
>
>  I have QuickFix 1.13.3 installed on two machines, one as acceptor, one as
> initiator. The symptom:Anytime a ResendRequest is received, the QuickFix
> that receives it is NOT incrementing  the NextTargetMsgSeqNum for that
> ResendRequest message. The ResendRequest is correctly handled, but now the
> system that received the original ResendRequest will think the *other*
> system is out of sync, as soon as that other system sends another message,
> as it's MsgSeqNum will be one too large. This results in the two systems
> trading ResendRequests, once each heartbeat.
>
> Looking in the source, it appears this happens only when persistMessages is
> NOT on. In that case, the code (line ~400 of Session.cpp) generates a
> SequenceReset and returns. The code never reaches the end where (line ~482)
>
>   if( !isTargetTooHigh(msgSeqNum) && !isTargetTooLow(msgSeqNum) )
>     m_state.incrNextTargetMsgSeqNum();
>
> is done.
>
> I fixed it by putting all the code that re-sends the messages in an else
> clause, and commenting out the line with the return, so that the
> incrNextTargetMsgSeqNum still gets called.
>
>
> In testing this, I found that UseLocalTime=Y appears to have no effect in
> the settings, and UTC time was still used for the times I specified in the
> settings. I stepped through the code that initializes the settings and it is
> correctly picking up the values from the file, and using LocalTimeOnly
> container. The problem appears to be in the fact that the TimeRange
> container does not do anything differently to accept a LocalTimeOnly as
> compared to a UtcTimeOnly object. What's going on here?? I just get around
> it now by setting different times...
>
>
> In testing that, I changed the settings on my server (running the accepter)
> for the session time and restarted it. Upon doing that, the first couple
> Logon attempts were refused (server sent a Logoff message in response to my
> Logon message), and did not increment its sending message number in the
> process. Eventually it sorted it's sh*t out and sent a Logon response with
> the message number jumped up to the correct value. I have not tried to track
> this down.
>
>
> MY MAIN QUESTION:
> Does this sound like I'm doing something wrong? Not setting it up
> correctly? Are these problems normal? Or is this version of Quickfix just
> horribly buggy? How long has this version been released? I am using it for
> about a week and have found what appears to be 4 serious bugs... Either I am
> the FIX newbie that I am, or this version of Quickfix is not ready for the
> primetime.
>
> I guess that's it. I appreciate any feedback anyone has for me on these
> issues.
>
> Thanks,
> Scott
>