Standard Durables

Quality of Service

A standard durable ensures that every message is received and acknowledged by its subscriber.

If the subscriber does not acknowledge a message, the persistence store retains the message, and the subscriber automatically recovers the message.

Delivery Count and Maximum

A standard durable with a nonzero prefetch setting 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 standard durable retains each message until its subscriber acknowledges it.

If a prefetch is nonzero, and 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 the 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 the prefetch is nonzero, and 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 is not delivered to a subscriber unless the durable is rewound. For more information see, Rewinding a Durable.

Subscribers

A standard durable can serve at most one subscriber at a time. That subscriber receives the entire message stream.

If a standard durable already serves a subscriber object in one client process, and another client process creates a subscriber that connects to the same standard durable, then the persistence store resolves collisions in favor of the more recent subscriber, deactivating the older durable subscriber. See "SUBSCRIBER_FORCE_CLOSE” in TIBCO FTL Development.

If a subscriber to a standard durable already exists within a client process, and the same client process subsequently attempts to create another subscriber on the same standard durable, that subscriber create call fails.

Direct Path

Administrators may configure a direct path from publisher to subscriber. In this arrangement, a standard durable provides a parallel path though the persistence service, which adds an intermediary hop. This durable path is only for recovering missed messages. See “Stores for Delivery Assurance” in TIBCO FTL® - Enterprise Edition Administration.

However, in some use cases, a direct path is not required for standard durables:

• When using a message broker
• When using a wide-area store

Content Matcher

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

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

Acknowledgments

A standard durable tracks acknowledgments from subscribers.

Dynamic Durable

Before a program can create a dynamic standard durable, the administrator must have already enabled standard 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® - Enterprise Edition Administration

When a program subscribes to a static standard 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® - Enterprise Edition Development.

• Optional: Content Matcher

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