As we know SIBus messaging engines allow using either data store or file store for persistence. These two stores together are termed as message store. In this blog, I will try to provide some tips to avoid common problems while using file store.
The Log file is circular write ahead log file containing data pertaining to active transactions and the data which is not yet written to the permanent store file. So, if SIBus uses file store, the data would be first written to this log file before it is moved into the permanent store file. Moving the data to the permanent store file is done at regular intervals using an internal process called checkpoint. Checkpoint is triggered for every 5000 transactions or when the log file is nearly full.
The Permanent Store file contains the data that survives beyond messaging engine restart or failure. It contains data pertaining to persistent (Reliable Persistent and Assured Persistent) messages.
The temporary store file stores the data related to non-persistence messages and does not survive after restart or failure of messaging engine. This file is used to store the spilled messages (Express Non Persistence, Reliable Non Persistence messages) from the java heap memory. Spilling occurs to effectively maintain java heap memory to accommodate new messages. These messages never go to log file. The temporary store file contents are truncated when the messaging engine starts.
Significant performance gains can be achieved by allocating dedicated disks for file store with their own battery systems for power backup. This essentially results into synchronous writes going into to cache rather than to disk which gains the performance. As the disks are backed up by their own power system, it would not cause cached data to be lost incase of general power failure.
Log File size
The log file size is determined by the amount of persistent data that is being written to the file store. It also determines the largest size of the messages that can be sent to file store. When the log file can not accommodate the data being written, a LogFileFullException is thrown. This is usually because a single large message or multiple large messages are sent before the file store can move them to the store files. If this exception is encountered the size of the Log file will need to be increased. Usually the default size is sufficient. Only testing using the extremes of message size and load expected can accurately determine if the default size is too small.
It is not always beneficial to simply allocate a significantly larger log file size. Because the size of the log file is used by algorithms that control the internal workings of the file store. An overly large log file will result in increased memory usage.
Permanent Store File size
The default permanent store file sizes are usually sufficient. However, only testing of a specific configuration can reveal what size permanent store file might be required. This testing involves filling each queue point with messages of the largest expected size (until the message high limit threshold is reached) when the permanent store file is set to unlimited. The permanent store file size reached during this test, plus the log file size is usually a safe size to use as the maximum permanent store file size.
The permanent store file maximum size is not intended to be the limit that prevents further messages being sent. This is because it is not only message data that is stored in the permanent store file. Queue data and protocol state data is also stored in the permanent store file. Instead, the high threshold of the queues should be used to prevent any more messages being sent.
Permanent store reports full when a contiguous free space can not be obtained to write entire log file. This might also happen when the log file size is over the half of the permanent store file. Once a store file is full, there is a remote chance that consuming all the messages will not result in the store being able to receive more data. At this point of time ObjectStoreFullException is thrown.
A rule of thumb to calculate minimum and maximum store file sizes is as follows.
Minimum store file size = 2 * log file size
Maximum store file size = 2 * minimum store file size + log file size
Should this problem occur, increasing the size of the store file by the size of the Log file and restarting the messaging engine will resolve the issue.