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 a set of .summary files, instead of a single one. The 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 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 the 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, the entire number of parts is registered at StorageID.state with the 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 in backward 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:
EngineSettings::fileBasedStorageSegmentSizeto non-zero and start Engine;
EngineSettings::fileBasedStorageSegmentSizeto 0, start Engine;
Also, assume another situation.
EngineSettings::fileBasedStorageSegmentSizeto 0 and start Engine;
EngineSettings::fileBasedStorageSegmentSizeto non-zero value which is less than the StorageID.summary size, start Engine;
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:
Session initiator(senderCompId, targetCompId, dictionary, &listener, SessionStorageType::FileBased);
File-Based Storage without segmentation