Recovery

Table of Contents

• Backup connection
• Store-and-forward
• Gap fill
• Fail-over

Backup connection

FIX Antenna allows specifying the primary and backup connection for a session. The backup connection is used instead of the primary, when the latter is not available. Parameters of the backup connection are specified in the Engine::Session::connect() method. The session changes the primary connection to the backup (and back) when the Engine::Session::switchConnection() method is called. If the enableAutoSwitchToBackupConnection_ session parameter is enabled (refer to the Engine::SessionExtraParameters), the session changes the primary connection to the backup automatically after reconnect attempts exceed Reconnect.MaxTries. If the cyclicSwitchBackupConnection_ session parameter is enabled, the session automatically switches the primary connection to the backup and back in cycle.

The Engine::SessionExtraParameters::keepConnectionState_session parameter means that the session will continue using the current storage and values of the InSeqNum and OutSeqNum. Otherwise the new storage will be created and seqNums will be reset.

For example:

Appl appl; // : see the Application class 
 
// Creat session Sender:Target that keeps state on connection switch
SessionExtraParameters params;
params.keepConnectionState_ = true;
 
Engine::Session *sn = Engine::FixEngine::singleton()->createSession(appl, "Sender", "Target", FIX44, &params, persistent_storageType); 
 
Engine::SessionBackupParameters backupParams;
backupParams.host_ = "localhost";
backupParams.port_ = 5679;
backupParams.params_ = NULL;
 
// establish connection with the primary connection - localhost:4567
sn->connect(30, "localhost", 4567, &backupParams);
// wait until connection is established 
appl.waitUntilLogon();
 
// switch to the backup connection - localhost:5679
sn->switchConnection();
appl.waitUntilLogon();

Store-and-forward

FIX Antenna follows two main rules:

1. Outgoing message is stored to the file and then sent
2. Incoming message is stored to the file after it is processed (optional)

There are two very important consequences of these rules, which in combination with FIX sequencing and retransmission make losing messages in FIX Antenna impossible:

1. If an application crashes during incoming message processing, the message will not be stored and after the connection is restored the sequence number too high will be identified and a resend request will be sent.
2. If an application crashes before a message is delivered to the counter-party, the counter-party will identify a gap after the connection is restored and send a request for retransmission.

Gap fill

Gap fill is a standard FIX mechanism for identifying and resolving message loss. It is based on sequencing messages in each direction, resend request mechanism, PosDup flag and sequence reset.

When the session identifies a "sequence number too high" problem it sends a resend request message asking for retransmission of lost messages. The opposite side resends requested messages with PosDupFlag set to "Y". Session level messages are not resent. The sequence reset is used to keep sequence numbers consistent during resending i.e. it is sent instead of session level messages or when messages to be resent are absent. The sequence reset gap fill message is used to skip a set of messages, it informs counterparty what sequence number to expect next.

FIX Antenna resolves the gap fill automatically, i.e. no manual work is required. However it is possible to intervene into the standard mechanism. The Engine::Application::onResend method is called each time an application level message is resent. It is possible to return "false" for those messages, which should not be resent; sequence reset will be sent instead.

Fail-over

FIX Antenna comes with a basis for failover. This means that if an application crashes FIX Antenna will fully restore its state after the next initialization as it was before crash. No information will be lost.