OnixS C++ FIX Engine  3.24.0
API Documentation
File-Based Session Storage

File-Based Session Storage keeps messages in set of files arranged in directory, and specified by OnixS::FIX::EngineSettings::logDirectory settings. This storage usually keeps data at two kinds of files: messages are kept in StorageId.summary and session state kept in StorageId.state file. StorageID is a generic name of storage and it is available through the OnixS::FIX::Session::storageId() method.

In particular cases, it is needed to save space on disk and there is no need to keep the whole history of incoming and outgoing messages. To satisfy such requirements, File Based Storage could be configured to store messages in set of .summary files, instead of single one. Entire set of logged messages is split through several files called as "segments", and the oldest segments could be just removed without affection on the Engine functionality. Details of this mode are described in the next section.

Segmented File Based Storage

Segmented mode of file based storage is initiated when the OnixS::FIX::EngineSettings::fileBasedStorageSegmentSize setting is configured to non-zero before Engine startup. This value specifies the maximum size of each one file where incoming and outgoing messages stored and affects all sessions created.

Names of segments composed as: StorageID[-part-N].summary, where:

During message interchange, files are created and fulfilled by following common algorithm:

So during a long session, there is a set of files created: StorageID.summary, StorageID-part-1.summary, StorageID-part-2.summary, etc. Oldest messages are arranged at StorageID-part-1.summary, and the freshmost ones - at StorageID.summary and StorageID-part-N.summary, where N is of maximum value.

At the same time, entire number of parts is registered at StorageID.state with key of FilePartCount. For instance, if there are 5 parts (StorageID.summary and StorageID-part-1.summary - StorageID-part-4.summary) the following line will be written at StorageID.summary:


When the session restarts only a particular part of the entire set of segments, they could be used to retrieve the resend request queue. The exact number of segments, used to retrieve this queue, depends on the OnixS::FIX::EngineSettings::resendingQueueSize value and on traits of messages, which were written in .summary files. Messages are retrieved inbackward order, from the tail to a start of the file set, so segment content is analyzed in the following order:

Unneeded segments (which obviously will have lowest N in -part-N suffixes) are never touched by Engine and could be deleted or backed up by a user.

While the session is active, all segments, which could be used by the service resend request, are kept opened to prevent unexpected deleting. When new messages arrived, older segments are closed and detached from Engine, and could be removed or backed up by a user.

Combinations between segmented and non-segmented File Based Storages

It is important to understand that Engine decides whether the storage working mode is just on the startup. Assume the following situation:

Also assume another situation.

Checking integrity of segmented File Based Storage

During startup the Engine, check integrity of segmented file storage. The storage is treated as "correct" when all files, required to retrieve a resending queue, are available and accessible to read. If some files are not available, or inaccessible behavior depends on OnixS::FIX::EngineSettings::ignoreFileBasedStorageIntegrityErrors setting:

Attaching File Based Storage

Session initiator(senderCompId, targetCompId, dictionary, &listener, SessionStorageType::FileBased);


Segmented storage

EngineSettings settings;
Session initiator(senderCompId, targetCompId, dictionary, &listener, SessionStorageType::FileBased);

File Based Storage without segmentation

EngineSettings settings;
Session initiator(senderCompId, targetCompId, dictionary, &listener, SessionStorageType::FileBased);