FTL Stores Overview

Note: Release 10.2 of EMS introduced a redesigned version of FTL stores with improved performance capabilities and more robust fault-tolerance and disaster recovery features. Release 10.3 introduces asynchronous disk persistence. It is highly recommended that existing FTL stores deployments be migrated to the current release. Refer to the EMS 10.3 Release Notes for information on migrating deployments from EMS 10.1 and EMS 10.2.

FTL stores have a somewhat unique configuration and deployment model in comparison to other EMS storage types. When using FTL stores, the EMS server runs as a service within an FTL server – which is an umbrella process that launches and manages a number of messaging services that constitute a TIBCO FTL deployment. The integration of EMS with FTL in this manner reduces latency in communication between the EMS server and its FTL backend. Additionally, it also allows EMS to make use of FTL’s disaster recovery capabilities.

In terms of functionality, FTL stores are similar to file-based stores. When using FTL stores, all pending persistent message information and state information is maintained in EMS server memory and persisted on disk via FTL. Keeping this information in memory reduces the amount of disk reads required and facilitates faster message processing

As with file-based stores, an EMS server using FTL stores must recover all state information and pending message information before it can activate. Depending on the situation, this is achieved either by reading the contents of all stores from disk via FTL, or by processing the data that has already been replicated to the EMS server by FTL.