Last-Value Durable Reference

Quality of Service

A last-value durable divides its input message stream into output sub-streams based on the string value of a key field in each message. For each sub-stream, the durable stores the most recent message.

A last-value durable ensures that every new subscriber immediately receives the most recent message, if one is stored. The subscriber continues to receive the sub-stream of subsequent messages until the subscriber closes, but without any assurance of delivery.

Message Retention

A last-value durable retains only one message for each output sub-stream.

Subscribers

A last-value durable can support multiple subscribers simultaneously.

Each subscriber can receive exactly one output sub-stream.

Direct Path

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

Content Matcher

Subscribing to a last-value durable requires a content matcher.

For static last-value durables, the admininstrator configures the key field name, and the program must match a specific value of that field in the create subscriber call.

For dynamic last-value durables, the program must supply the key field name as a property in the create subscriber call, and match a specific value of that field.

The key field must contain data of type string. Content matchers must match a string value against the key field.

Notice that each subscriber must test the key field, but each subscriber can match a different value of that field. The value determines the output sub-stream that the subscriber requests from the last-value durable.

Acknowledgments

A last-value durable does not track acknowledgments from subscribers.

Unlike standard and shared durables, a subscriber to a last-value durable subscriber does not consume messages from the durable. Instead, new subscribers to a sub-stream continue to receive the stored value until a publisher sends a new value, which replaces it.

Dynamic Durable

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

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.

For example, suppose the store does not yet contain a durable named ticker. A program then creates a subscriber to a last-value durable named ticker, with key field name Symbol and content matcher {"Symbol":"IBM","Exchange":"NYSE"}. In response, the store creates a new dynamic durable named ticker, with content matcher {"Symbol":true,"Exchange":"NYSE"}. That is, the new durable generalizes from the key field name to a content matcher clause that tests for the presence of the key field rather than a specific value, and integrates the rest of the clauses from the subscriber’s content matcher.

If the create subscriber call does not supply a content matcher, the new durable uses only the key field clause as its content matcher.

Subsequent subscribers to the durable must specify compatible content matchers: that is, they must be identical except for the key field value, which can be different. A subscriber create call with an incompatible content matcher throws an exception.

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).