Uploaded image for project: 'QuickFIX/J'
  1. QuickFIX/J
  2. QFJ-791

An unexpected field in a repeating group makes QuickFIX/J fail to detect the number of repeating groups correctly

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Default
    • Resolution: Fixed
    • Affects Version/s: 1.5.3
    • Fix Version/s: 1.6.4
    • Component/s: Engine
    • Labels:
      None

      Description

      Hi,

      When an unexpected tag (a tag not defined in the data dictionary) is present in a repeating group QuickFIX/J fails to detect the number of repeating groups correctly. For example in the following message the unexpected tag 58 is present at the end of the first leg (600, 687, 654, 566, [58]):

      8=FIX.4.4 9=233 35=AE 34=1 49=SENDER 52=20140610-15:04:53.377 56=TARGET 31=5.6789 32=1000 60=20140610-15:04:53.367 75=20140101 570=N 571=ABC1234 555=2 600=L1-XYZ 687=333 654=ABC1234-L1 566=1.2345 58=TXT1 600=L2-XYZ 687=777 654=ABC1234-L2 566=2.3456 10=017

      With tag 58 in the first leg, the number of repeating groups detected by QuickFIX/J message parser will be 1 (incorrect)!
      Remove tag 58 from the first leg and QuickFIX/J will sees the number of repeating groups for as 2 (correct).

      This is very dangerous because it makes a QuickFIX/J applications very sensitive to changes in repeating groups. For example, when a trading platform decides to add a new tag to the repeating group, an existing application will fail completely because of the incorrect number of repeating groups detected. Instead the application should simply ignore the new tag, especially when AllowUnknownMsgFields=Y.

      Of course when the new tag is added to the data dictionary this problem will not occur, however, the current behaviour of the repeating group parsing logic is inconsistent with the message body parsing logic, inconsistent with the configuration (AllowUnknownMsgFields=Y) and generally counter-intuitive.

      Regards,
      Andrzej Hajderek

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                chrjohn Christoph John
                Reporter:
                andrzej_ls Andrzej Hajderek
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: