[QFJ-121] Duplicate fields and other problem give false body length validation error Created: 04/Jan/07  Updated: 12/Apr/07  Resolved: 11/Feb/07

Status: Closed
Project: QuickFIX/J
Component/s: Engine
Affects Version/s: 1.0.4
Fix Version/s: 1.1.0

Type: Improvement Priority: Default
Reporter: Scott Harrington Assignee: Steve Bate
Resolution: Fixed Votes: 0
Labels: None

Attachments: File quickfixj-ValidateMessageStructure.patch    

 Description   

I have encountered a counterparty whose FIX 4.2 Logon message has "98=0" appearing twice. It's clearly wrong, but I couldn't find anywhere in the spec that prohibits it.

We choke on these messages pretty early with the not-too-helpful (see QFJ-65) message "Invalid message: Actual body length=x, Expected body length=x".

The Message.bodyLength() method adds up the lengths of the fields after they've been parsed and grouped as per the DataDictionary, thus the duplicated "98=0" field only gets counted once.

I have added a crude "ValidateMessageStructure=N" work-around for myself which disables the whole bodyLength() validation step (as well as the innocent checkSum and header field order checks). I will attach this hack as a patch against SVN revision 571.

A better solution would be to re-think the bodyLength() validation, could it not just examine the raw (unparsed, ungrouped) message at this point, like checkSum() does?

 Comments   
Comment by Scott Harrington [ 04/Jan/07 ]

This patch is against SVN Revision 571.

Comment by Steve Bate [ 09/Jan/07 ]

I agree it's a good idea to improve the error messages. The FIX specification does prohibit repeated tags except in a repeating group (where the tag can't repeated within a single group). I'll investigate improving the messages for the 1.1.0 release.

Comment by Steve Bate [ 11/Feb/07 ]

I've modified the message to not check for the correct length. As noted, duplicate fields and other problems can cause an apparent body length mismatch even though the raw message has the correct body length. The FIX protocol codec will not pass a message with a bad body length anyway, so I removed that check from the message-level validation. I also added a unit test for the case described in the issue (duplicate 98=0 tags).

Generated at Sat Nov 23 11:33:15 UTC 2024 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.