WRITER_DATA_LIFECYCLE QoS Policy

This QoS policy controls how a DataWriter handles the lifecycle of the instances (keys) that the DataWriter is registered to manage. This QoS policy includes the members in .

DDS_WriterDataLifecycleQosPolicy

Type	Field Name	Description
DDS_Boolean	autodispose_unregistered_instances	RTI_TRUE (default): Instance is disposed when unregistered. RTI_FALSE: Instance is not disposed when unregistered.
struct DDS_Duration_t	autopurge_unregistered_ instance_delay	Determines how long the DataWriter will maintain information regarding an instance that has been unregistered. By default, the DataWriter resources associated with an instance (e.g., the space needed to remember the Instance Key or KeyHash) are released lazily. This means the resources are only reclaimed when the space is needed for another instance because max_instances (see RESOURCE_LIMITS QosPolicy) is exceeded. This behavior can be changed by setting autopurge_unregistered_instance_delay to a value other than INFINITE. After this time elapses, the DataWriter will purge all internal information regarding the instance, including historical DDS samples even if max_instances has not been reached.

You may use the DataWriter’s unregister() operation (Registering and Unregistering Instances) to indicate that the DataWriter no longer wants to send data for a Topic. This QoS controls whether or not Connext DDS automatically also calls dispose() (Disposing of Data) on the behalf of the DataWriter for the data.

Unregistering vs. Disposing:

• When an instance is unregistered, it means this particular DataWriter has no more information/data on this instance.
• When an instance is disposed, it means the instance is "dead"—there will no more information/data from any DataWriter on this instance.

The behavior controlled by this QoS applies on a per instance (key) basis for keyed Topics, so when a DataWriter unregisters an instance, Connext DDS also automatically disposes that instance. This is the default behavior since autodispose_unregistered_instances defaults to TRUE.

Use Cases for Unregistering without Disposing:

There are situations in which you may want to set autodispose_unregistered_instances to FALSE, so that unregistering will not automatically dispose the instance. For example:

• In many cases where the ownership of a Topic is EXCLUSIVE (see the OWNERSHIP QosPolicy), DataWriters may want to relinquish ownership of a particular instance of the Topic to allow other DataWriters to send updates for the value of that instance. In this case, you may want a DataWriter to just unregister an instance—without disposing it (since there are other writers). Unregistering an instance implies that the DataWriter no longer owns that instance, but it is a stronger statement to say that instance no longer exists.
• User applications may be coded to trigger on the disposal of instances, thus the ability to unregister without disposing may be useful to properly maintain the semantic of disposal.

When you delete a DataWriter (Creating DataWriters), all of the instances managed by the DataWriter are automatically unregistered. Therefore, this QoS policy determines whether or not all of the instances are disposed when the DataWriter is deleted when you call one of these operations:

• Publisher’s delete_datawriter() (see Creating DataWriters)
• Publisher’s delete_contained_entities() (see Deleting Contained DataWriters)
• DomainParticipant’s delete_contained_entities() (see Deleting Contained Entities)

When autodispose_unregistered_instances is TRUE, the middleware will clean up all the resources associated with an unregistered instance (most notably, the DDS sample history of non-volatile DataWriters) when all the instance’s DDS samples have been acknowledged by all its live DataReaders, including the DDS sample that indicates the unregistration. By default, autopurge_unregistered_instances_delay is disabled (the delay is INFINITE). If the delay is set to zero, the DataWriter will clean up as soon as all the DDS samples are acknowledged after the call to unregister(). A non-zero value for the delay can be useful in two ways:

• To keep the historical DDS samples for late-joiners for a period of time.
• In the context of discovery, if the applications temporarily lose the connection before the unregistration (which represents the remote entity destruction), to provide the DDS samples that indicate the dispose and unregister actions once the connection is reestablished.

This delay can also be set for discovery data through these fields in the DISCOVERY_CONFIG QosPolicy (DDS Extension):

• publication_writer_data_lifecycle.autopurge_unregistered_instances_delay
• subscription_writer_data_lifecycle.autopurge_unregistered_instances_delay

Properties

It does not apply to DataReaders, so there is no requirement that the publishing and subscribing sides use compatible values.

This QoS policy may be modified after the DataWriter is enabled.

Related QoS Policies

• None.

Applicable Entities

• DataWriters

System Resource Considerations

None.

© 2016 RTI