Restoring Session State from Log Files

Choose the procedure that matches your intent: continue the same FIX session after a normal restart, recover after a crash, or reset sequence numbers by agreement with the counterparty. Deleting session files is not a recovery procedure. Preserve the state and messages needed for continuation and replay. See Selecting Storage for Session Messages Logging for storage tradeoffs.

Before reconnecting

Before initiating or accepting a connection that continues an existing sequence:

• Keep application sends, scheduling, and automatic reconnection stopped.
• Recreate the session with the same identity, including any custom session key, storage directory, and relevant storage settings.
• Construct the session with keepSequenceNumbersAfterLogout = true, set OnixS::FIX::Session::resetLocalSequenceNumbersOnLogon to false, and do not request a reset in a custom Logon or through the setResetSeqNumFlag argument.
• If the session is scheduled, use OnixS::FIX::Scheduling::SequenceNumberResetPolicy::Never.
• Check startup errors, OnixS::FIX::Session::outSeqNum() (the next outgoing number), and OnixS::FIX::Session::inSeqNum() (the next expected incoming number).

A counterparty Logon with ResetSeqNumFlag=Y can reset the numbers even when the local session is an acceptor. See Resetting Message Sequence Numbers via ResetSeqNumFlag Field.

MemoryBased storage cannot restore state or replay history after the process stops. To continue the session, restore externally maintained state and reconcile it with the counterparty. For Pluggable storage, follow the implementation's recovery contract.

Normal restart: continue the same session

Note

Construct the running session with keepSequenceNumbersAfterLogout = true before a restart is needed. This constructor-only setting cannot be changed during shutdown. If it was false during Logout, reconcile the resulting state with the counterparty.

1. Stop application sends and connection automation, then disconnect the session.
2. Shut down all sessions and then the Engine as described in Shutting down the whole Application. Preserve the storage files; see Write completion and replay.
3. Restart the Engine, recreate the session, and complete the checks in Before reconnecting before reconnecting. Built-in file storage restores the saved sequence numbers and messages still available for replay.

Crash recovery: reconcile saved state

After abrupt termination, saved state can differ from the messages already exchanged. Asynchronous storage can lose queued writes, leaving the next outgoing number below the number expected by the counterparty.

1. Keep the session stopped and preserve a copy of its storage files and Engine log.
2. Recreate the session with the previous identity and storage configuration, then complete the checks in Before reconnecting.

Important

If an existing .state file cannot be opened or parsed, the Engine reports OnixS::FIX::EngineErrorReason::RestoreSessionStateError through OnixS::FIX::IEngineListener::onError, but session construction can continue with fresh storage and both next sequence numbers set to 1. OnixS::FIX::EngineSettings::ignoreFileBasedStorageIntegrityErrors does not control this fallback. Treat the callback or unexpected sequence numbers as a failed recovery.

1. Resolve missing files, access failures, and corruption before connecting. For segmented storage with nonzero OnixS::FIX::EngineSettings::fileBasedStorageSegmentSize, see Checking integrity of segmented File-Based Storage for the outcome when required segments are missing.
2. Reconcile both sequence-number directions and affected business messages with the counterparty. A stale incoming number can cause the Engine to request messages already processed by the application. If they are replayed with PossDupFlag=Y, do not repeat completed business actions.
3. If an adjustment is agreed, call OnixS::FIX::Session::outSeqNum(value) for the next outgoing number and OnixS::FIX::Session::inSeqNum(value) for the next expected incoming number while the session is disconnected. The adjustment is not an immediate durability checkpoint and does not recover missing messages or reconcile business transactions.
4. Connect using the agreed numbers and reset policy. If Logon is rejected because its sequence number is too low, stop automatic retries and reconcile again. Apply the replay requirements in Resending Messages before resuming application work.

Agreed sequence reset: start a new sequence

A reset is a coordinated change to the FIX session, not a substitute for recovering lost messages. Use a daily reset only when required by the counterparty agreement.

1. Agree when both sides will reset and how outstanding messages and business transactions will be reconciled.
2. Stop application sends and connection automation, disconnect the session, and keep its object alive.
3. Call OnixS::FIX::Session::resetLocalSequenceNumbers(). The method backs up the current log files and resets both local sequence numbers to 1; it does not reset the counterparty's state. Use it instead of deleting storage files.
4. Reconnect using the agreed reset procedure. If it uses ResetSeqNumFlag, follow Resetting Message Sequence Numbers via ResetSeqNumFlag Field. Check the resulting numbers before resuming application sends or scheduling.

See also Resetting Message Sequence Numbers for the local reset API.