Persistence: Stores and Durables

Persistence provides for persisted messages and persisted interest. That is, a set of FTL servers can store messages for consumers that are offline or disconnected, and then deliver those messages when consumers are available again.

Your choice of messaging architecture and messaging model determines whether you use persistence. See FTL Configuration Overview for background.

In FTL, the broker-based messaging architecture is inherently persistent. Persistence can be tuned to trade off between reliability and performance as desired.

If you are using the destinations messaging model, then you must also use the broker-based messaging architecture. Destinations will be mapped to persistence stores, which are managed by persistence clusters.

If you are using the content matching messaging model in combination with a broker-based architecture, then you will use persistence. Application endpoints will be mapped to persistence stores, which are managed by persistence clusters.

If you are using the content matching message model in combination with a peer-to-peer architecture, then you do not need to use persistence. In advanced cases, you may optionally configure persistence as a backup for the peer-to-peer message path. In those cases, application endpoints will be mapped to both persistence stores and transports.

For an introduction to persistence in FTL, see Persistence Concepts. Then, for users of the content matching messaging model, see Persistence Stores for Content Matching.

For information on how to configure persistence, see Configuring Persistence and FTL Server GUI: Configuration.

For information on how to monitor and manage persistence, see Persistence Monitoring and Management and FTL Server GUI: Monitoring and Administration.