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