What is the messaging contract of QuickFIX/J? Do I get guaranteed in order delivery?

user_1519574 0
Viewed 473

I am just getting started with QuickFIX/J. One thing I am confused reading their documents is that what exactly is the messaging contract ensured by QuickFIX implementation of the FIX protocol?

In particular, I know FIX has a built-in sequence number based mechanism which implementations can leverage to handle out of order, missing or duplicated messages. But does QuickFIX/J already has the capability built in? As an application using QuickFIX/J to communicate with a fix engine, can I assume:

  1. Messages delivered to my app from QuickFIX/J are always in order.

  2. There is no missing messages (QuickFIX/J will automatically handle the re-requesting)

  3. There is no duplicated messages (QuickFIX/J can look at the sequence number recieved so far and filter out possible duplication)

  4. If the remote fix engine crashes, I will reconnect with the last known sequence number automatically when the engine comes back

  5. If my app crashes, when it restarts will it be able to automatically resume the session from the previous known sequence number? (e.g. will there be any out of the box sequence number persistence mechanism?)

quickfixj fix-protocol
1 Answers

QuickFIX/J implements the FIX session protocol, so it handles all the session-level stuff (connecting, sequence numbers, ...) for you.

  1. Yes, but there may be duplicates, see 3.
  2. Yes.
  3. No, actually QFJ will still forward possible duplicates to your app because you still might want to handle those. You need to filter them by yourself if you want to, based on 43/PossDupFlag.
  4. Yes.
  5. Yes. QFJ has some out of the box persistence mechanisms like FileStore, JdbcStore, MemoryStore. You could also implement your own Store if you need to.

Here is a link on how to create a QFJ application, in case you haven't already found it: https://github.com/quickfix-j/quickfixj#creating-a-quickfixj-application

user_49623550
Related