DDS — Ref-85 Garbage_collection_of_disposed_instances

In the current specification, the applications are fully responsible
for the resource usage. Applications have means to detect when
lifecycles end and resources can be freed. However even if
applications are to be written correctly not all cases are covered and
some situations potential produce garbage, that is memory that remains
in use and never reclaimed.

The following are potential scenarios:

Instances become disposed but the application does not 'take' the
sample and therefore does not allow the middleware to end the
lifecycle and remove the state regarding the instance

Instances that no longer have any "active" writers and consequently
get no more samples.

Even if the application 'takes' the disposed instance or instances
with no writers it is not always possible for the middleware to
reclaim the resources. This can occur in two cases; in case of the
service keeping Transient and Persistent data and in case of
incomplete MultiTopic samples. In both cases an immediate removal of
samples is not desirable but eventually the samples should be removed

On the one hand deleting the instances immediately will potentially
cause problems since late coming readers may require the disposed
instances, e.g. reallocating consumers requiring disposed instances to
finish interrupted cleanup actions or MultiTopics joining Topics with
different lifecycles.

On the other hand the disposed instances cannot be kept
indefinitely. Doing this will eventually flood the system, especially
for Topics with increasing key-values.

The solution is to keep them for a certain duration and then reclaim
the resources the question is how long this duration should be?

Note that, in general, just because a sample has been disposed the
middleware cannot reclaim all the resources on it either on the writer
side or on the reader side. For the middleware to reclaim resources it
is necessary that the instance is also unregistered; otherwise
disposing would automatically relinquish ownership which is not the
desired behavior.

This applies both to the writer side, the reader side, and/or the
transient/persistent durability service.

On the writer side it is therefore clear. Resources are only fully
reclaimed when the instance is unregistered.

So the tricky issue is how to handle the case where an instance has no
writers, whether it had been disposed or not, whether there are
samples in the queue or not. Nominally we notify the application of
this event by some means (see Issue #84). The application should then
take the samples.

One approach would be for the middleware to keep some resources around
for a certain duration (DISPOSE_LIFESPAN) in case this was just a
transient situation and the instance appears again. This treats the
DISPOSED_NO_WRITERS similarly to the DISPOSED_EXPLICIT

**PROPOSAL**

Add a new QoS on the DataReader called NO_WRITERS_LIFESPAN with a
single Duration_t field "duration". It is mutable with a default
value equal to DURATION_INFINITY. This represents the duration for
which the DataReader should keep the knowledge of an instance once it
detects it has NO_WRITERS.

After the instance has no writers the middleware is not required to
keep the information about the instance any longer than the
NO_WRITERS_LIFESPAN. The implication is that if an instance becomes
DISPOSED_NO_WRITERS and the application does not take the instance for
a time that exceeds the NO_WRITERS LIFESPAN the application could miss
the fact that the instance has DISPOSED and has no writers.

see below