DURABILITY QosPolicy

Because the publish-subscribe paradigm is connectionless, applications can create publications and subscriptions in any way they choose. As soon as a matching pair of DataWriters and DataReaders exist, then data published by the DataWriter will be delivered to the DataReader. However, a DataWriter may publish data before a DataReader has been created. For example, before you subscribe to a magazine, there have been past issues that were published.

The DURABILITY QosPolicy controls whether or not, and how, published DDS samples are stored by the DataWriter application for DataReaders that are found after the DDS samples were initially written. DataReaders use this QoS to request DDS samples that were published before they were created. The analogy is for a new subscriber to a magazine to ask for issues that were published in the past. These are known as ‘historical’ DDS data samples. (Reliable DataReaders may wait for these historical DDS samples, see Checking DataReader Status and StatusConditions.)

This QosPolicy can be used to help ensure that DataReaders get all data that was sent by DataWriters, regardless of when it was sent. This QosPolicy can increase system tolerance to failure conditions.

Exactly how many DDS samples are stored by the DataWriter or requested by the DataReader is controlled using the HISTORY QosPolicy.

For more information, please see Mechanisms for Achieving Information Durability and Persistence.

The possible settings for this QoS are:

This QosPolicy includes the members in DDS_DurabilityQosPolicy. For default settings, please refer to the API Reference HTML documentation.

DDS_DurabilityQosPolicy

Type

Field Name

Description

DDS_DurabilityQosPolicyKind

kind

DDS_VOLATILE_DURABILITY_QOS:
Do not save or deliver old DDS samples.

DDS_TRANSIENT_LOCAL_DURABILITY_QOS:
Save and deliver old DDS samples if the DataWriter still exists.

DDS_TRANSIENT_DURABILITY_QOS:
Save and deliver old DDS samples using a memory-based service.

DDS_PERSISTENCE_DURABILITY_QOS:
Save and deliver old DDS samples using disk-based service.

DDS_Boolean

direct_
communication

Whether or not a TRANSIENT or PERSISTENT DataReader should receive DDS samples directly from a TRANSIENT or PERSISTENT DataWriter.

When TRUE, a TRANSIENT or PERSISTENT DataReaderwill receive DDS samples directly from the original DataWriter. The DataReadermay also receive DDS samples fromPersistence Service1Persistence Service is included with the Connext DDS Professional, Evaluation, and Basic package types. It saves DDS data samples so they can be delivered to subscribing applications that join the system at a later time (see Introduction to RTI Persistence Service (Chapter 1 on page 1)). but the duplicates will be filtered by the middleware.

When FALSE, a TRANSIENT or PERSISTENT DataReader will receive DDS samples only from the DataWriter created by Persistence Service. This ‘relay communication’ pattern provides a way to guarantee eventual consistency.

See RTI Persistence Service.

This field only applies to DataReaders.

With this QoS policy alone, there is no way to specify or characterize the intended consumers of the information. With TRANSIENT_LOCAL, TRANSIENT, or PERSISTENT durability a DataWriter can be configured to keep DDS samples around for late-joiners. However, there is no way to know when the information has been consumed by all the intended recipients.

Information durability can be combined with required subscriptions in order to guarantee that DDS samples are delivered to a set of required subscriptions. For additional details on required subscriptions see Required Subscriptions and AVAILABILITY QosPolicy (DDS Extension).

Example

Suppose you have a DataWriter that sends data sporadically and its DURABILITY kind is set to VOLATILE. If a new DataReader joins the system, it won’t see any data until the next time that write() is called on the DataWriter. If you want the DataReader to receive any data that is valid, old or new, both sides should set their DURABILITY kind to TRANSIENT_LOCAL. This will ensure that the DataReader gets some of the previous DDS samples immediately after it is enabled.

Properties

This QosPolicy cannot be modified after the Entity has been created.

The DataWriter and DataReader must use compatible settings for this QosPolicy. To be compatible, the DataWriter and DataReader must use one of the valid combinations shown in Valid Combinations of Durability ‘kind’.

If this QosPolicy is found to be incompatible, the ON_OFFERED_INCOMPATIBLE_QOS and ON_REQUESTED_INCOMPATIBLE_QOS statuses will be modified and the corresponding Listeners called for the DataWriter and DataReader respectively.

Valid Combinations of Durability ‘kind’

 

 

DataReader requests:

VOLATILE

TRANSIENT_LOCAL

TRANSIENT

PERSISTENT

DataWriter offers:

VOLATILE

4

incompatible

incompatible

incompatible

TRANSIENT_
LOCAL

4

4

incompatible

incompatible

TRANSIENT

4

4

4

incompatible

PERSISTENT

4

4

4

4

Related QosPolicies

Applicable Entities

System Resource Considerations

Using this policy with a setting other than VOLATILE will cause Connext DDS to use CPU and network bandwidth to send old DDS samples to matching, newly discovered DataReaders. The actual amount of resources depends on the total size of data that needs to be sent.

The maximum number of DDS samples that will be kept on the DataWriter’s queue for late-joiners and/or required subscriptions is determined by max_samples in RESOURCE_LIMITS Qos Policy.

System Resource Considerations With Required Subscriptions”

By default, when TRANSIENT_LOCAL durability is used in combination with required subscriptions, a DataWriter configured with KEEP_ALL in the HISTORY QosPolicy will keep the DDS samples in its cache until they are acknowledged by all the required subscriptions. After the DDS samples are acknowledged by the required subscriptions they will be marked as reclaimable, but they will not be purged from the DataWriter’s queue until the DataWriter needs these resources for new DDS samples. This may lead to a non efficient resource utilization, specially when max_samples is high or even UNLIMITED.

The DataWriter’s behavior can be changed to purge DDS samples after they have been acknowledged by all the active/matching DataReaders and all the required subscriptions configured on the DataWriter. To do so, set the dds.data_writer.history.purge_samples_after_acknowledgment property to 1 (see PROPERTY QosPolicy (DDS Extension) ).

© 2018 RTI