Re: [Quickfix-developers] OpenFIX Testing Service

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

Actually, looking at the actual test case regarding the OriginalSeqNo 
problem, this is what it states:

Test Description:
g.  PossDupFlag set to Y and OrigSendingTime not specified.

Expected Result:
1) Send Reject (session-level) message referencing missing 
OrigSendingTime (>= FIX 4.2: SessionRejectReason = "Required tag 
missing")
2) Increment inbound MsgSeqNum

So it seems to me that QuickFIX is in fact doing the right thing in 
this case.  Ignore the previous code snippet I sent.  It is wrong 
anyway.

--oren

On Mar 25, 2005, at 11:11 AM, James Wiggs 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
>
>
>  Folks,
>
>    I am currently testing our QuickFIX-based application against
> the OpenFIX (TransactTools) public testing service.  Overall, the
> testing has been going fairly well, but it has also showed up a
> few gaps in my knowledge -- and what look to be QuickFIX bugs.  I
> am using QuickFIX 1.9.2, and running the FIX 4.2 session-level
> tests.  There are a few which fail for reasons that appear to be
> QuickFIX-related.  First, my own failures:
>
> 1) When I send a manual sequence reset, it appears that the value
> of the sequence number in the Session does not get updated.  I had
> thought that I could get around this by using the Session method
> generateSequenceReset() but that is a private method.  Now I think
> I can fix the problem by sending the SequenceReset method, then
> calling setNextSenderMsgSeqNum() to set the value in the Session,
> but should I pass it "NewSeqNo" or "NewSeqNo+1"?
>
> 2) Due to the problem mentioned in (1) my sequence numbers are now
> out of sync and I can no longer successfully log in to the service.
> The Logon attempt occurs and then the Session immediately logs off
> with an error "MsgSeqNum too low...".  Obviously we don't want to
> exchange messages if the sequence numbers are out of synch, but my
> question is: how do you fix the problem if you can't even log on
> to do a SequenceReset?  I'm clearly missing something very obvious
> here.  Can someone fill me in on what the procedure should be in
> this case with QuickFIX?
>
>    Next, the things that appear to be QuickFIX-related:
>
> 1) Test 2t - Invalid First Three Fields.
> OpenFIX testing service creates and sends a TestRequest with tags
> 8, 9 and 35 deliberately in the wrong order.  My application fails
> this test every time, but I can't figure out if it is a problem
> with QuickFIX or with the test.  They state that the expected flow
> is to ignore the message, drop it without incrementing the incoming
> sequence number, and log a warning message.  I see the following
> in my event log:
>
> 20050325-16:47:21 : Invalid message: Header fields out of order
> 20050325-16:47:33 : Sent test request TEST
> 20050325-16:47:33 : MsgSeqNum too high, expecting  37 but received 39
> 20050325-16:47:33 : Sent ResendRequest FROM: 37 TO: 0
> 20050325-16:47:33 : Received SequenceReset FROM: 37 TO: 40
>
>    But the message that comes back is they received a Heartbeat
> message from me and that "This type of message is not allowed at
> this time."  As I see it, this could mean that in fact my app *is*
> doing the right thing, dropping the message, logging the warning,
> and then continuing on as normal, sending heartbeats every 30
> seconds, and they just aren't closing up the test before the next
> heartbeat goes through.  I could be wrong, though.  Has anyone
> successfully run through all of these tests?  Were there any
> gotchas?
>
> 2) Test 2f - Invalid OrigSendingTime on PossDup Message
> The test complains that they received a Session Reject with a
> "Required tag missing" as the reason for the reject, but that I
> should send SessionRejectReason="SendingTime accuracy problem"
> instead, then send a Logout referencing the bad SendingTime
> value, wait for the Logout response (or wait 2 seconds) and do
> a disconnect.  Obviously, the logout/disconnect didn't happen.
> Is this really an error in QuickFIX, or should I be capturing it
> and implementing this logic at the App level instead?
>
> 3) Test 14m - Missing Conditionally Required Field
> They state that at FIX 4.2 or later, this should not generate a
> Session-level Reject, but rather a BusinessMessageReject.  But
> QuickFIX generates a Session Reject.  And what's more, it did
> this even when I was *not* explicitly trying to get the field in
> question in my onMessage handler.  Is this an oversight on my
> part, should I be building this logic into the onMessage handler
> and manually generating BusinessMessageRejects?  And if so, how
> do I prevent the Session level from rejecting it before I even
> get the message into the handler?
>
>    This has been my first really extensive testing outside my
> own systems, and it has been a real learning experience.  I'd
> appreciate any feedback to help me through the last of this
> work.
>
> thanks,
> Jim
>
> -- 
> James Wiggs <wi...@wi...>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>