Normally, when data is stale in DDS it is disposed automatically. There are other ways that this can occur though.

• When the auto-dispose option in the QoS is enabled then when a subscriber detects that a writer has become unresponsive (or has been deleted) then the data is disposed implicitly for all instances of that writer.
• It can also be achieved explicitly by the writer using the dispose method (or one of the related calls) for a specific instance (see below)

Explicitly disposing data

You can select an instance by providing an instance handle or data-sample with the keys filled in (internally, key fields will be used to lookup the instance handle) to any of the dispose methods eg. dispose, dispose_w_timestamp, writedispose etc. This is the same idea as when you do a write (dispose is the same as write except it only changes state so it doesn’t carry any sample data except key fields).

You can’t ‘delete’ by query or any other way at the writer side. Disposing marks the data as stale and should not be confused with deleting (as if it never existed). You can retrieve a single instance handle using lookup_instance but there’s no shortcut to select a subset based on a query. Within the C++11 binding there are additionally some convenience functions that take iterators instead of a single sample/handle.

Why you might manually dispose the data.

It may be that a writer knows data is stale and so doesn’t want those values delivered by the durability service. Data may stay valid for minutes/hours/weeks and the durability service rightfully deliver those values for late-joining subscriber, but if there’s an onward connection issue and the writer knows sample-states are unreliable it may need to selectively delete them according to the key that’s already part of the data.