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

What is the intention of the SendResetSeqNumFlag setting?

    Details

    • Type: Other
    • Status: Closed
    • Priority: Default
    • Resolution: Fixed
    • Affects Version/s: 1.0.5
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      What is the intention of the SendResetSeqNumFlag setting?

      The Java constant for this field is Session.SETTING_RESET_WHEN_INITIATING_LOGON and the Configuration section of the QuickFIx/J User Manual has the description "Send a sequence number reset when initiating a logon" and says the default is "N". This implies (to me) that an initiator session with this flag set should always reset its sequence numbers before logging in, sending a Logon(A) request with and 34=1 and 141=Y every time; it's fairly easy to see why such behaviour shouldn't be the default as it risks undelivered messages from the previous session being lost.

      However QuickFIX/J actually only seems to use the setting - in Sesson.isResetOnLogonRequested() - to decide whether to set 141=Y in a Logon(A) when the expected sequence numbers for both sides have ALREADY been set to 1, and it has no real effect if ResetOnDisconnect or ResetOnLogout are set, the two most common situations for this, as these cause 141=Y to be set anyway if the sequence numbers have been reset. I would suggest this behaviour IS required in most instances and the default should be "Y".

      The only other time I can find the setting being checked is in Session.nextLogon(Message) to avoid rejecting an incoming Logon(A) message with the sequence number higher than we expect; not sure why this is the case, although I've not really thought about it.

      So, what is the desired behaviour? Is there a bug in QuickFIX/J (i.e. should this setting really trigger a Session.reset() every time?) or does the documentation maybe need to be made more specific?

        Attachments

          Activity

            People

            • Assignee:
              admin Steve Bate
              Reporter:
              raimesh Rob Gilliam
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: