quickfix-j / quickfixj

QuickFIX/J is a full featured messaging engine for the FIX protocol. - This is the official project repository.
http://www.quickfixj.org
Other
955 stars 611 forks source link

Should choosing setting undefined tags on the group/body be configurable? #371

Open philipwhiuk opened 3 years ago

philipwhiuk commented 3 years ago

In the case of:

https://github.com/quickfix-j/quickfixj/blob/4d5401979b1046b68e2196aec37f56a6a3c46416/quickfixj-core/src/test/java/quickfix/MessageTest.java#L1784

If you have the following:

453=2|448=A|20000=MISC|448=B|

then it is pretty obvious that 20000 should be on the repeating group

But if you have

453=2|448=A|448=B|20000=MISC

then there's no information in the message as to whether the correct interpretation puts 20000 on the group or on the body.

At the time of parsing we don't provide the parser any information whether we're in the obvious case or the non-obvious case.

Is there a case for adding:

<ConsiderUnknownTagsInGroup>Y/N</ConsiderUnknownTagsInGroup>

Or (with the group count info considered by the parser)

<ConsiderTrailingUnknownTagsInGroup>Y/N</ConsiderTrailingUnknownTagsInGroup>

Pre fix to QFJ-791 the default was N. Now with the fix the default is Y.

chrjohn commented 3 years ago

I think there might be a case for adding this. I am just asking myself if it always will behave as you want. What tells you that the next unknown tag that you will receive in two weeks from now will not be part of the group but should be added to the root message?

junjiequ123 commented 9 months ago

assume there are multiple groups in FIX message, to properly parse them, suggest to have a group end to indicate the scope of group tags

chrjohn commented 9 months ago

@junjiequ123

assume there are multiple groups in FIX message, to properly parse them, suggest to have a group end to indicate the scope of group tags

Could you shortly explain? Maybe with an example?

junjiequ123 commented 9 months ago

sure, when we process FIX message from plain text, found tags ( 10002 in this case) will be ignored after a "group"

..... 453=1448=81447=D452=10010000=TEST10KTAG the reason behind is the "group" treats 10002 as a member, which means no other "group"s could exists after a "group"

expected : assume we put a tag called "ENDOFGROUP" with number 957, and enhance a clear group definition in text format, such as 453=1448=81447=D452=100957=110000=TEST10KTAG

where 453=1 indicates a new "group" with 1 set of tags, and 957=1 indicates the end of this groups, echo 1 set of tags. we can repeat this with more "groups", can also put extra normal tags after "groups"