Shared Durable Reference

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, or until its delivery count reaches the maximum limit.

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.

Dynamic Durable

Before a program can create a dynamic shared durable, the administrator must have already enabled shared dynamic durables on the endpoint (see “Enabling Dynamic Durables” and “Dynamic Durable Template Definition Reference,” both in TIBCO FTL Administration).

When a program creates a dynamic shared durable, it must supply the following information in the subscriber create call:
  • Endpoint Name
  • Durable Name
  • Optional: 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 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 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” and “Durable Definition Reference,” both 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.

Related reference