Endpoint Store Inboxes

Starting from FTL 6.8.0 and later, inbox subscriber applications can create an inbox durable in the endpoint's configured store, as long as there is no direct path transport. If the inbox subscriber's endpoint has a direct path transport, the transport is used and no inbox durable is created, even if the endpoint has a store.

This behavior is controlled by the realm property use_endpoint_store_for_inbox, which is set to true by default in new realm configurations. If migrating from a release prior to 6.8.0, the endpoint store inbox store behavior is not enabled by default. The pre-FTL 6.8.0 inbox behavior of routing to one of two inbox stores (ftl.system.inbox.store or ftl.routing.inbox.store) is used if use_endpoint_store_for_inbox is set to false.

When sending to an endpoint store inbox, the message matches only the corresponding inbox durable in the endpoint's store. All non-inbox durables are excluded, even if those durables use null matchers. In this way, it is possible to use the same store for one-to-many and one-to-one sends. Releases prior to FTL 6.8.0 relied on dedicated stores for inbox traffic.

Endpoint store inboxes are functional in all store configurations (including disk persistence and/or swapping) and in any zone type (hub-spoke, full-mesh, hub-spoke-1hop). In releases prior to FTL 6.8.0, the dedicated inbox stores were configured to be non-replicated and to use a publisher mode of store_send_noconfirm. If that behavior is desirable, consider using a similarly configured store for inbox messages.

The FTL request-reply APIs use inboxes implicitly, and therefore will use an endpoint store inbox if that behavior is enabled. If the requestor wishes to use separate stores for sending requests and receiving inbox replies, the application may specify an explicit reply endpoint.

Changing the value of the use_endpoint_store_for_inbox property will require a restart of all store-based inbox publishers and subscribers.