[QFJ-650] Wrong handling of messages without sequence number (MsgSeqNum) - leads to wrong Reject message and increase of target sequence number Created: 09/Nov/11  Updated: 01/Dec/11  Resolved: 01/Dec/11

Status: Closed
Project: QuickFIX/J
Component/s: Engine
Affects Version/s: 1.5.1
Fix Version/s: 1.5.2

Type: Bug Priority: Major
Reporter: Christoph John Assignee: Christoph John
Resolution: Fixed Votes: 0
Labels: session


 Description   

If QF/J receives a message which is missing tag 34 it rejects the message by the means of a session-level Reject (MsgType=3). This is not according to the spec which suggests to send a Logout message in that case (e.g. FIXT1.1 spec, p.40, "What constitutes a garbled message").

But the really troubling point IMHO is that QF/J increases the sender sequence number anyway. This is done in method generateReject( Message, int, int ) and so the sequence numbers are out of sync starting from that point. The generateReject method even checks if the MsgSeqNum field is set and if not assumes '0' as default. (which can be seen as error output: (Reject sent for Message 0: Required tag missing:34). Moreover, the resulting Reject message is missing the 45/RefSeqNum field, which is a required one!

QFJ-557 is addressing a similar topic with regard to the increase of the target sequence number in the generateReject() method. However, the missing MsgSeqNum is a special case and should be answered by a Logout and not a Reject.

Probably there should be a check for the MsgSeqNum in Session.next( Message ) which triggers a call of disconnect() and prints out a message to the error log. Would the Session.next(Message) method be the correct point for such a check?

Thanks,
Chris.


Generated at Sat Nov 23 07:28:49 UTC 2024 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.