quickfix-developers

[Quickfix-developers] OpenFIX Testing Service

[James W. <wi...@wi...>]

 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...>

Re: [Quickfix-developers] OpenFIX Testing Service

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

> 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"?

You should pass it NewSeqNo.  NewSeqNo is the next number the 
counterparty should expect to receive.  Note that the method you are 
calling is set*Next*SenderMsgSeqNum, indicating that this is the next 
sequence number that will be used.   We should probably add a public 
generateSequenceReset( NewSeqNo ) convenience method.

> 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?

Set the ResetSeqNum flag = Y in your toAdmin when the logon gets sent 
out.  Also make sure to set both your sequence numbers to 1.

> 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?

Yeah, I can't think of a scenario where a Heartbeat is ever not 
allowed. On the face of it this looks perfectly normal to me.

> 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?

Yeah, we should change this.  I'm looking at the spec and it states 
that if the OrigSendingTime is not available, it should be set to the 
same value as SendingTime.  So we can change the relevant code from 
this:

     if ( !header.isSetField( origSendingTime ) )
     {
       generateReject( msg, 1, origSendingTime.getField() );
       return false;
     }
     header.getField( origSendingTime );

To this:

     if ( !header.isSetField( origSendingTime ) )
       origSendingTime = OrigSendingTime( sendingTime );
     else
       header.getField( origSendingTime );

> 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?

Yeah, we should be rejecting conditional fields with business level 
rejects.  I'll post a patch for this.  I have no idea why you would be 
rejected before getting into the handler.  What message and field was 
this?

--oren

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
>