EMI.STAT provides well-structured and unified interface to system statistics with caching capabilities. The information itself is gathered by the external modules (EMI.STAT Modules) that could be supplied or extended by 3rd parties.

Statistics that are collected from the system could be of any given nature depending on the EMI.STAT Modules that are supplied. Some data could be collected instantaneously other may take seconds or minutes to collect or access. This diversity poses certain problems for the front-end implementations as well as for the EMI-RPC protocol itself. Namely, if the data collection takes time, then EMI-RPC should have a dedicated connection open while waiting and the browser-based front-end may timeout in waiting. At the same time, front-end may be satisfied with the old statistics information if it is available, if it will avoid waiting for the new one to be collected. Even more, it may be so that there is no need to re-fetch the statistics for a while once it has been collected.

To handle these and similar cases EMI-RPC Server implements a caching system that automatically stores the results of the requests in a tree-like structure, where keys are identifying the branches of the tree. This structure provides maximum flexibility for the caching, but because it is possible to requests only part of the information (i.e. very specific key), the cached information for the rest of the tree will become older then that particular key. Following request to retrieve larger portion of the tree may result in the inconsistent data. In order to retrieve the latest information the request should supply the “refresh” parameter.

NOTE! While caching is implemented to make the retrieval of the statistics more front-end friendly, it may play a trick when the retrieved data is inconsistent internally or outdated. Front-end designer should always take care of how the caching is manipulated.