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

When a gap fill satisfies a resend request, QF does not realize it

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Default
    • Resolution: Cannot Reproduce
    • Affects Version/s: 1.2.1
    • Fix Version/s: None
    • Component/s: Engine
    • Labels:
      None

      Description

      In our production environment, we saw the following scenario:
      They log on w/ 687
      We send resent request from 684 to 0
      They send a resend request (their #688)
      They send gap fill from MsgSeqNum=684 to NewSeqNo=688.
      They send us 689.
      QF did not recognize that the resend request had been fulfilled, so it did not send another resend request when it saw 689.
      The counterparty was never going to send us 688 otherwise - they had already sent it (and indeed we acted on it).
      So we ended up not processing any of their messages (sequence number too high), and eventually disconnected.

      We tracked the problem down to the
      boolean verify(Message msg, boolean checkTooHigh, boolean checkTooLow)
      method around line 1168. If the MsgSeqNum is at or beyond the end of the resend range waiting to be satisfied, then the resend request will be deemed satisfied. But for gap fills, it should really consider the entire range of the gap, i.e., MsgSeqNum to NewSeqNo - 1, which it does not. NB that in some scenarios, the next inbound message will clear the problem. But not in the one above.

      We are running 1.2.1. Based on inspection of the code, I believe this also affects 1.3.x and 1.4.x.

      Will attach a patch, diff.txt.

        Attachments

          Activity

            People

            • Assignee:
              chrjohn Christoph John
              Reporter:
              ryarran1 Rhys Yarranton
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: