Shared Durables

A shared durable apportions a message stream among its subscribers.

Quality of Service

A shared durable ensures that every message is received and acknowledged by a subscriber. Each subscriber receives a portion of the input message stream. Together, the subscribers receive the entire message stream.

If a subscriber does not acknowledge a message, the durable can redeliver it to another subscriber.

Delivery Count and Maximum

A shared durable counts the delivery attempts for each message. If the administrator sets an optional maximum limit for a durable, the durable can discard a message after the number of failed delivery attempts exceeds that limit.

While this mechanism never discards a message before reaching the limit, it does not guarantee a discard at exactly the limit.

Message Retention

A shared durable retains each message until a subscriber acknowledges it.

If a delivery limit is set, a message may be discarded once the maximum number of delivery attempts has been reached for that message. This is true regardless of whether a retention time is set.

If message TTL is enabled, a message may be discarded once the message's age exceeds the TTL. This is true regardless of whether a retention time is set.

If a retention time is set, the message may not be deleted immediately after being acknowledged. Instead, the message is retained until the message's age (as measured from publish time) exceeds the retention time. However, an acknowledged message cannot be delivered to a subscriber unless, the durable is rewound. For more information, seeRewinding a Durable

Subscribers

A shared durable can support multiple subscribers simultaneously.

Each subscriber receives a portion of the message stream.

Direct Path

Subscribers receive messages only through the persistence store. The shared durable semantic precludes direct-path delivery, even if a direct path is configured.

Content Matcher

A shared durable accepts, but does not require, a content matcher.

If it has a content matcher, then every subscriber must specify either an identical content matcher, or no content matcher.

Acknowledgments

A shared durable tracks acknowledgments from subscribers.

Shared Durable Browsing

Use a client API to browse messages stored in a shared durable, for example, to run analytics on the data or delete a message. Messages are browsed from oldest to newest. A matcher can be used to browse a subset of the messages. Browsing does not affect delivery of messages to subscribing clients. Messages can be delivered to other subscribing clients while simultaneously being browsed. The effective matcher is a logical AND of the browser matcher and the durable matcher.

Messages returned to a durable while a browser is running are not browsed unless the browser is restarted or re-created. This may happen, for example, because a consumer failed while processing some messages.

In the event of leader failover or connection loss, browsers need to be restarted or closed.

Warning: Creating too many browsers is not recommended, as it can put a strain on the persistence service resources, including both CPU and memory usage.
Monitoring

The REST API and UI show the number of browsers on a shared durable. See GET persistence/clusters/<clus_name>/stores/<stor_name>/durables.

Logging

A log message warns if there are too many browsers on a shared durable.

Dynamic Durable

Before a program can create a dynamic shared durable, the administrator must have already enabled shared dynamic durables on the endpoint, In TIBCO FTL® - Enterprise Edition Administration, see “Enabling Dynamic Durables” and “Inbox Durable Templates".

When a program creates a dynamic durable, it must supply the following information in the subscriber create call:

  • Endpoint Name
  • Durable Name
  • Key Field Name

    When creating a new dynamic durable, the key field name becomes part of its content matcher.

  • Content Matcher

    When creating a new dynamic durable, the content matcher becomes part of the new durable. The content matchers of subsequent subscribers to the durable must be identical.

If a durable with the specified durable name and key field name already exists, that durable forwards messages to the new subscriber.

If a durable with the specified durable name does not yet exist, the persistence store creates a dynamic durable using the durable name, key field name, and content matcher supplied in the subscriber create call.

Static Durable

Before a program can subscribe to a static durable, the administrator must have already defined that durable in the persistence store associated with the endpoint. See “Defining a Static Durable” in TIBCO FTL Administration.

When a program subscribes to a static shared durable, it must supply the following information in the subscriber create call:

  • Endpoint Name
  • Durable Name or Subscriber Name

    To understand this distinction, see “Durable Subscribers” in TIBCO FTL Development.

  • Optional: Content Matcher

    The content matcher must either be null, or be identical to the content matcher of the durable. The best practice is to supply null.