The FIX Protocol has a wealth of guaranteed delivery mechanisms, resending messages as needed. But some transactions have a shelf life. There are many reasons you might want to prevent the re-sending of certain messages.
- Prevent old quotes from clogging the line after a disconnect
- Prevent old executions from being re-sent after a problem
- Protect your platform from bad replay requests
- Protect your business from FIX outage queue floods
- Conform to nonstandard counterparty requirements
- Control when and how old/stale messages are handled
- Control your engine’s behavior when clocks are unsynced
- Avoid start-of-day resend floods
The Expire Module
One of the Flyer FIX Engine‘s included standard modules, this checks all outgoing FIX messages and FIX message replays, preventing them from going out if the timestamp is not within a specified threshold.
The module is very simple to configure.
<?xml version="1.0" encoding="UTF-8" ?> <modules> <module class="flyer.example.modules.expire.ExpireMessages" enabled="true" init-method="init" name="expire-BuySide" salience="4" scope="session"> <include-session begin="FIX.4.2" sender="BuySide" target="SellSide"/> <expire message="ORDER TIME EXCEEDED" threshold-future="20000" threshold-past="20000" command-name="BuySide"> D </expire> </module> </modules>
In this example, NewOrderSingle(D) messages with timestamps that are 20 seconds in the past or future will be expired. If the message was routed from another session, a reject message is sent back with Text(58) set to “ORDER TIME EXCEEDED”. The engine command for configuring this module will be “expire-BuySide”.
The Use Case
Anywhere you need to control the age of messages your engines send, this module is the quickest way to enforce timestamp requirements. It’s your first line of defense, trivial to configure, and included in the Flyer FIX Engine.