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