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

quickfixj ignores the first message on sequence reset

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Not a bug
    • Affects Version/s: 1.5.3, 1.6.0
    • Fix Version/s: None
    • Component/s: Build
    • Labels:
      None
    • Environment:
      this happens on window and linux

      Description

      Hi,
      I am experiencing the following serious fix issue. This could be config but I am not convinced.

      I have used both quickfixj 1.5.3 and the newer 1.6.0 (snapshot)

      I get the following issue

      I connect to the fix server periodically there is a message that comes in out of sequence

      From the event log we get the following issue

      20141215-00:01:02: Received logon
      20141215-14:41:57: MsgSeqNum too high, expecting 473 but received 474:

      Execution Report

      Field Field Name Value
      8 BeginString FIXT.1.1
      9 BodyLength 956
      35 MsgType Execution Report (8)
      34 MsgSeqNum 474

      20141215-14:41:57: Enqueued at pos 474: Field
      Field Name Value
      8 BeginString FIXT.1.1
      9 BodyLength 956
      35 MsgType Execution Report (8)
      34 MsgSeqNum 474

      20141215-14:41:57: Sent ResendRequest FROM: 473 TO: 473
      20141215-14:41:57: MsgSeqNum too high, expecting 473 but received 474:
      8 BeginString FIXT.1.1
      9 BodyLength 956
      35 MsgType Execution Report (8)
      34 MsgSeqNum 474

      and at this point we get a general repeat of this deadlock

      From mesages log you can see that a resend request got sent
      Field Field Name Value
      8 BeginString FIXT.1.1
      9 BodyLength 68
      35 MsgType Resend Request (2)
      34 MsgSeqNum 441
      49 SenderCompID NOMXFIXPTM
      52 SendingTime 20141215-14:41:57.405
      56 TargetCompID MA
      7 BeginSeqNo 473
      16 EndSeqNo 0

      the next message from MA is

      Field Field Name Value
      8 BeginString FIXT.1.1
      9 BodyLength 1095
      35 MsgType Execution Report (8)
      34 MsgSeqNum 473
      43 PossDupFlag Y
      49 SenderCompID MA
      52 SendingTime 20141215-14:41:57.415
      56 TargetCompID NOMXFIXPTM
      122 OrigSendingTime 20141215-14:41:43
      37 OrderID 1240469
      527 SecondaryExecID 8534860-0

      And MA keep sending trades with the next sequence up but our client is having none of it.

      20141215-14:41:57: Already sent ResendRequest FROM: 473 TO: 473. Not sending another.

      The thing that seems to be wrong is the first message sent over after the resend request gets ignored, instead it sees the message after that.
      Restarting can put this back to the correct sequencing and thus out of the deadlock

      I am hoping someone might have some insight into this issue.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              wanny Emma Wansbrough
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: