-
Key: DDS-119
-
Legacy Issue Number: 6825
-
Status: closed
-
Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
-
Summary:
Section 2.1.3 on the QoS table. The description of the
TIME_BASED_FILTER QoS says""The setting of this QoS is incompatible with RELIABILITY policy set
to ALL"First there is no such setting for reliability policy. It intended to
say it is incompatible with RELIABILITY 'RELIABLE' and HISTORY
'KEEP_ALL'.However it is unclear why it is necessary introduce such
incompatibility. It would be better to interpret the meaning of
RELIABLE and KEEP_ALL to mean that the application desires that all
samples that pass whichever filters have been specified are propagated
reliably and kept by the middleware until they can be delivered to the
DataReader. In other words, the RELIABILITY and HISTORY policies apply
after the "filter-type" policies apply. The filters determine what is
of interest, the reliability whether samples lost by the transport
should be retried and the HISTORY whether to keep old values that have
not been delivered to the application once a new value
exist. Interpreted this way all combination of the above policies are
sensical. This approach also extends to the ContentFilteredTopic**PROPOSAL**
Remove that comment from the TIME_BASED_FILTER QoS
Add a third paragraph to section 2.1.3.8 that explains that it is
indeed possible to specify RELIABILITY RELIABLE, and a HISTORY
KEEP_ALL and still set a TIME_BASED_FILTER. The paragraph would say:The setting of a TIME_BASED_FILTER, that is, the selection of a
minimum_separation with a value greater than zero is compatible with
all settings of the HISTORY and RELIABILITY QoS. The TIME_BASED_FILTER
specifies the samples that are of interest to the DataReader. The
HISTORY and RELIABILITY affect the behavior of the middleware with
respect to the samples that have been determined to be of interest to
the DataReader, that is, they apply after the TIME_BASED_FILTER has
been applied.Specify that that if the reliability is RELIABLE then in steady-state
it should behave as-if the last sample passes the
TIME_BASED_FILTER. In other words, in steady state the last sample
should eventually become available to the receiver. -
Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
-
Disposition: Resolved — DDS 1.0
-
Disposition Summary:
see below
-
Updated: Fri, 6 Mar 2015 20:58 GMT
DDS — Ref-104 Coupling_bwn_TIME_BASED_FILTER_and_RELIABILITY
- Key: DDS-119
- OMG Task Force: Data Distribution Service FTF