File Store Feature
Version: 17.07
Supported Since: 17.01
File Store Feature
File Store is a collection of pooled, ram-disk based, performance optimized and reusable set of files. File Store Feature provide a simple API to obtain/release above mentioned files from/to File Store. These files will be called as "Message files" here onwards because of the nature of the use case of these files.
Message Files are optimized for performance very well, they are created and managed on a ram mounted disk in order to provide the expected writing/reading speed. These Message Files are used to store the content of an input message during the message’s life time within the UltraESB-X. Reading and writing to the obtained message files are done through java File Channels instead of streaming methods in order to ensure the highest possible performance. Message Files are pooled, giving the ability to obtain a Message File from File Store when needed in no time. When File Store initializes for the first time it creates initial number of message files and fill up the message file pool to be used when message listening started. Once a borrowed message file from the pool is no longer used in the message or when the message life time expires it should be return to the pool back again. There are APIs defined in the File Store feature for invoke these actions.
File Store Feature has a handy tool which has the ability to track the files given out from the store in order to report back if any of them hasn’t returned back to the store. This tool is called *Leak Detector#, and can be configured in different detection levels as well as leak checking intervals etc. For production system it offers a slim non-performance impacting level which records few key data points and for the testing environments there is a extreme level which records everything including a stack trace at where the message file is borrowed to support debugging.
File Store Feature Configuration
Here are the configuration properties you can used in File Store feature property file
| Property Name | Property Description | Possible Values |
|---|---|---|
initialSize |
Initial size of the pool of files used in File store. Defaults to 200 if not set the configuration property |
A positive integer, limited by the maximum number of file descriptors of the system |
stopThreshold |
Number of files which the File store should stop at expanding the initial pool size |
A positive integer equals or greater than initialSize, limited by the maximum number of file descriptors of the system |
warnThreshold |
Number of files which the File store should issue a warning at expanding the initial pool size |
A positive integer equals or greater than initialSize, limited by the maximum number of file descriptors of the system |
path |
Path in the file system where the ram-disk is mounted. Defaults to /tmp/ram |
Valid file system path |
leakDetection.level |
Detection level which the File Store should run, defaults to DISABLE level |
DISABLED, PRODUCTION, DEBUG, EXTREME |
leakDetection.leakCheckDelay |
Number of milli-seconds interval which the detection should run if leak detection is enabled |
A practical milli-second value. Do not set this to very low value(like 1 milli-second) |
leakDetection.leakSuspicionDelay |
Time in milli-seconds to suspect a message file has leaked after it issued from the file store |
An integer representing the milli-second value. Defaults to 120000 (2 minutes) |
Ram disk creation for File Store
A RAMDisk should be mounted and used for production systems for better performance. RAMDisk size should be decided
based on the average throughput and average size of the requests which the UltraESB-X instance supposed to handle.
To create a RAM disk at boot time, define your RAM disk parameters in the /etc/fstab file. An example
configuration that creates a 512M disk mounted at /tmp/ram on Debian/Ubuntu is as follows.
tmpfs /tmp/ram tmpfs defaults,size=512M
It is recommended that the RAM disk be mounted at /tmp/ram so that in-case of a mount failure at machine
restart, an error would be reported at ESB start-up time due to the non-availability of the /tmp/ram path as it is
at the temporary directory which will be empty.
|
APIs Java Docs
getTempFileEntity |
Parameters
Returns
Use this api to get a temp XMessageFileEntity from the file store. The returned entity will be naturally deleted at the end of the given message’s end of life. |
resetPayloadToFileBackedFormat |
Parameters
Use this api to reset a payload of a message to a new instance of MessageFileFormat which is consist of a new XMessageFileEntity. Created XMessageFileEntity will be naturally released at the end of the given XMessage’s life. This method will throw org.adroitlogic.x.api.IntegrationRuntimeException if couldn’t create a message file. |
releaseFile |
Parameters
Use this api to release a specific message entity from the file store, this call will either delete the actual file from the file system or released to the file pool depending on the FileStoreFeature implementation. This method will throw org.adroitlogic.x.api.IntegrationRuntimeException if couldn’t release the messageFile or delete underlying file. |
In this topic
In this topic