Working with disk storage

Overview

inspectIT stores most of the monitoring data in memory to improve performance and scalability on the CMR and to provide faster access to the data for the client. However, sometimes it is necessary to persist the important data to disk and have it for future reference. Until version 1.4 the only possibility was to save the invocation sequences to the local disk. This solution had some drawbacks:

Hard to share saved data between co-workers (usually the data was packed and sent by E-mail).
There was no backward-forward compatibility of the data (usually new versions could not open the data from old versions).
No possibility to automatically save the data received by CMR right away. The user had to select data to save afterwards.
Managing of the stored data was limited - users could not rename the data saved, mark the data, etc.
Opening/saving of the large (10,000+ children) invocation sequences was slow.

From the new version, the complete storage functionality is available that solves all the drawback mentioned above and brings many new features:

The first major change is that a Storage is created on the remote CMR repository. This enables easier sharing of the data between co-workers. Each CMR can have many storages.
Each Storage has a user-defined name and description.
From new version, all data saved in the storage is backward-forward compatible.
Except direct data saving, two new possibilities are available:
- Recording enables to automatically save data received by the CMR to a storage.
- Copy Buffer to Storage enables to copy complete or part of CMR's in-memory buffer to a storage.
Storages can be easily organized by Storage labeling.
Using the fast-serialization and Java 7 AIO the data saving/reading is fast and brings no performance problems to the CMR, even when huge amount of data needs to be stored to disk.

Storage life-cycle

Each Storage can be created only on the remote CMR, where one CMR can have unlimited numbers of storages. The storage has three states in its life-cycle:

When the storage is created, it is in the Writable state, meaning that this storage can be used to write data to. The storages in this state can not be read, even if some data is already written. The storages in this state can be deleted.
The Recording state is a special type of the Writable state and means that the Recording is currently active for the storage. Nevertheless, storage is still functioning as a Writable storage, thus any write operation can still be executed.
Once the storage has been finalized, it is in the Readable state. This storage can be now explored. The storage can not be returned to the Writable state once it has been finalized. The Readable storage will exist until it is deleted.

Configuration

Please refer to the page Storage configuration for the advanced user level configuration possibilities.