READER_DATA_LIFECYCLE
Controls how long a Subscriber retains samples that have been disposed of or are no longer associated with any Publisher.
What it controls
Delays before the Reader automatically purges disposed samples or samples with no active Writer.
Key settings
| Field | Default | Mutability |
|---|---|---|
autopurge_disposed_samples_delay |
infinity | Can be changed at runtime |
autopurge_nowriter_samples_delay |
infinity | Can be changed at runtime |
Compatibility role
Lifecycle and disassociation — governs how long disposed or orphaned instances remain in the Reader cache. Interacts with liveliness, durability, and writer autodispose settings.
When this conflicts
Reader Data Lifecycle takes part in the following QoS Guard rules. Each links to a full explanation with an example and a fix.
Related policies
Example
The RDLIFE QoS policy enables tiered instance management for improved efficiency. For example, in a temporary storage area where hundreds of pallets move quickly and historical positions become obsolete immediately, setting autopurge disposed samples delay to 0 seconds ensures that the cache is cleared as soon as a robot calls dispose(). This keeps the cache lightweight and prevents unnecessary memory growth. In contrast, for static, critical objects awaiting inspection after relocation, setting autopurge no writer samples delay to 300 seconds allows newly joined robots to continue inspection even after brief communication interruptions. By adjusting the reader-side delay values based on context, essential data can be preserved while irrelevant information is promptly discarded, ensuring efficient use of system resources.