Skip to content

DURABILITY

Determines how a late-joining Subscriber can receive previously published samples from a Publisher.

What it controls

How long and where previously published samples remain available for late-joining Readers.

  • VOLATILE: Does not send any previous samples to newly joined Subscribers.
  • TRANSIENT_LOCAL: Retains samples in the Publisher's HistoryCache while it is active, allowing late-joining Subscribers to access previously published data.
  • TRANSIENT: Preserve data after a Publisher has been terminated. Retains data in volatile memory.
  • PERSISTENT: Preserve data after a Publisher has been terminated. Uses non-volatile storage such as files or databases

Key settings

Field Default Mutability
kind volatile Can not be changed at runtime

Compatibility role

Matching and late join — Writer offered durability must be at least as strong as Reader requested durability (RxO). Affects replay to late joiners and interacts with lifespan, history, and reader purge settings.

When this conflicts

Durability takes part in the following QoS Guard rules. Each links to a full explanation with an example and a fix.

Best-effort delivery with transient-local durability with ReliabilityBreaks a guarantee Finite lifespan expires the history that durability should replay with LifespanBreaks a guarantee Disposed-sample purge that discards data durability should keep with Reader Data LifecycleBreaks a guarantee Manual enable with volatile durability drops pre-enable data with Entity FactoryWastes resources Partitions filter which retained samples a late joiner replays with PartitionWastes resources Subscriber requires more durability than the publisher offers with itselfWon't connect Unbounded durable writer cache under keep-all with HistoryWastes resources Durable replay resets the deadline timer for a late joiner with DeadlineWastes resources

Example

The DURABL QoS can be used to allow newly added or recovered robots to immediately access the same information, thereby improving both system robustness and collaborative efficiency. Data such as global maps or mission plans, whose availability must not depend on the lifespan of a specific robot, should remain accessible to robots that join after the Publisher has terminated or rebooted. In such cases, DURABL should be set to transient if data must persist throughout process restarts, or to persistent if it must survive system-wide reboots.