Skip to main content

Questions about FIX

My FIX Drop Copy service consumed a huge amount of space on disk. Why?​

Short answer: the most probable cause is that periodic message store cleaning is not configured.

FIX sessions come in two kinds:

  • Transient sessions do not remember what happened before a disconnect. Each connection starts with no knowledge of messages sent or missed during the previous one. FIX Market Data and FIX Order Entry gateways work this way, and clients are expected to send ResetSeqNum (141)=Y in the LOGON message.
  • Persistent sessions remember all messages, so that missed messages can be re-sent after a disconnect. The default Ember FIX Drop Copy and the FIX Store Gateway work this way. They should not be used with automatic ResetSeqNum (141)=Y on each LOGON.

A persistent session keeps every message it sends in its message store until sequence numbers are reset. If nothing ever resets them, the store grows without bound and eventually fills the disk.

Persistent sessions provide two ways to periodically reset sequence numbers and discard the stored messages:

  1. FIX session schedule. Both sides agree on when sequence numbers are reset by defining a coordinated daily or weekly schedule. See Drop Copy FIX Session Schedule.
  2. In-session sequence number reset. The FIX client sends a LOGON message with ResetSeqNum (141)=Y in the middle of a running session.

Think of a Drop Copy session as an important mailbox: it may hold messages the client has not yet received, so Ember cannot decide on its own when to empty it. For this reason, do not add resetSeqNum=true to Drop Copy settings as a way to limit disk usage. It clears the store on every LOGON, including messages the client may still need.

Bottom line: make it a step of onboarding each Drop Copy client to agree on when the mailbox is cleaned. Either define a FIX session schedule for that session, or get confirmation from the client that their side performs a periodic in-session sequence number reset.