Session disconnects on bad message

[Philip-Snijder]

I have an application which is used to retrieve trades, portfolios and product definitions from a third party system. Generally everything works fine, except that sometimes I receive a ‘bad’ message and the QuickFix library logs out the session:

Session FIX.4.4:A->B disconnecting: QuickFix.GroupDelimiterTagException: Group 146's first entry does not start with delimiter 55
at QuickFix.Message.SetGroup(StringField grpNoFld, String msgstr, Int32 pos, FieldMap fieldMap, IGroupSpec dd, DataDictionary sessionDataDictionary, DataDictionary appDD, IMessageFactory msgFactory)
at QuickFix.Message.FromString(String msgstr, Boolean validate, DataDictionary sessionDD, DataDictionary appDD, IMessageFactory msgFactory)
at QuickFix.Session.Next(String msgStr)
at QuickFix.SocketInitiatorThread.ProcessStream()
at QuickFix.SocketInitiatorThread.Read()

I would expect it to send a “Reject” to the server, but it just logs out

[Philip-Snijder]

Comment from Mike Gatny (on mailing list):

You won't get a change to handle this exception in user code -- I think we probably can and should be sending a Reject here instead, as you suggest. I think the change would be in Session.Next -- wrap the Message.FromString call in a try/catch and then generate a Reject in the catch case.

[gbirchmeier]

I tried to reproduce with an AT. In my attempt, the engine does trigger this exception, but otherwise ignores and proceeds past this message as if nothing erroneous just happened. It does not force a logout or disconnect. What I'm seeing is consistent with LSE's report (attn: @martinadams).

It's possible that some code change was made since this issue was first opened that changed the nature of the behavior from this error.

(The current behavior, of course, is still incorrect and must be fixed.)

[gbirchmeier]

Turns out that this situation has some history.

• This group problem was first reported back in 2012 - Null Ref exception when incoming msg has group that doesn't use delimiter #101 "Null Ref exception when incoming msg has group that doesn't use delimiter". I made some fixes that addressed half the problem.
• For the remaining part, I deemed it low-priority and opened Need corrections to parse-failure behavior on incoming messages #146 "Need corrections to parse-failure behavior on incoming messages".

Looking back on that, today-Grant does not approve of the work that 2012-Grant did. Woof. Time to fix it properly.

[gbirchmeier]

Yuck, #146 pretty clearly explains why I didn't fix it properly last time...

[gbirchmeier]

For posterity, here's LSE's report of the issue:

EDIT: It turns out that this doesn't actually recreate the bug. See the next comment for explanation.

This deals with a scenario where the engine logs out a session in response to a bad message, rather than sending a reject. An attempt at a repro, by sending in a message with a different invalid condition (out-of-order header fields) to that described in Issue #270, produced different symptoms. Here, QuickFIX/n recognised that the message was not valid and so did not process it further, but it did not provide any indication to the remote client that anything was amiss, as shown by the following client message log:

The saving grace here was that because QuickFIX/n did not accept the message, it still expected the subsequent message to have the same sequence number (8), and when the next (idle poll) message from the client had a sequence number of 9, QuickFIX/n sent a re-request and eventually logged off the connection when the re-request wasn’t satisfied.

Slightly different scenario, but same general problem.

[gbirchmeier]

@martinadams - actually, your attempt at reproducing this issue (in the above comment) is incorrect. Per FIX 4.4 v2 section "When to send a Session Reject vs. when to ignore the message", messages with mixed-up header fields count as "garbled" and should be ignored. So it turns out that the behavior you observed is actually correct (and is actually confirmed by Acceptance Test 2t_FirstThreeFieldsOutOfOrder.def).

To be clear, this is still a valid bug, reproducible via a GroupDelimiterTagException condition.

[martinadams]

Hmmm, I should have read the rule book first! :$