3.5.11. Where is filtering applied: writer vs reader side¶

Content filters may be evaluated on either side, as the DataWriter obtains the filter expression from the DataReader during discovery. Filtering on the writer side can save network bandwidth at the cost of increasing CPU usage on the writer.

3.5.11.1. Conditions for writer side filtering¶

A DataWriter will perform filter evaluation in the DataReader stead whenever all of the following conditions are met; filtering will otherwise be performed by the DataReader.

The DataWriter has infinite liveliness. See LivelinessQosPolicy.
Communication with the DataReader is neither intra-process nor data-sharing.
The DataReader is not using multicast.
The DataWriter is filtering for no more DataReaders than the maximum value set on reader_filters_allocation.
- There is a resource-limit policy on DataWriterQos that controls the allocation behavior of writer-side filtering resources. Setting a maximum value of 0 disables filter evaluation on the writer side. A maximum value of 32 (the default value) means the writer will perform filter evaluation for up to 32 readers.
- If the DataWriter is evaluating filters for writer_resource_limits.reader_filters_allocation.maximum DataReaders, and a new filtered DataReader is created, then the filter for the newly created DataReader will be evaluated on the reader side.

3.5.11.2. Discovery race condition¶

On applications where the filter expression and/or the expression parameters are updated, there may be a situation where the DataWriter will apply the old version of the filter until it receives updated information through discovery. This may imply that a publication made a short time after the DataReader updated the filter, but before the updated discovery information is received by the DataWriter, may not be sent to the DataReader, even if the new filter would have told otherwise. Publications made after the updated discovery information is received will use the updated filter.

If some critical application considers this race condition issue unbearable, filtering on the writer side can be disabled by setting the maximum value on reader_filters_allocation to 0.

3.5.11.3. Writer side filtering on late joiners Pro¶

By default, when a late joiner DataReader is discovered (non-volatile durability scenario), the DataWriter will not apply the filter for that DataReader on historical samples. This means that the late joiner DataReader will receive all historical samples, even those that would not match its filter, which could cause performance degradation on resource-limited systems.

It is possible however to configure a DataWriter to perform writer-side filtering on late joiners by setting the DataWriterQos property fastdds.content_filtering_on_late_joiners to true.

PropertyPolicyQos name	PropertyPolicyQos value	Default value
`"fastdds.content_filtering_on_late_joiners"`	`bool`	`false`

C++

DataWriterQos wqos;

// Enable content filtering on late joiners for this DataWriter
wqos.properties().properties().emplace_back(
    "fastdds.content_filtering_on_late_joiners",
    "true");

XML

<?xml version="1.0" encoding="UTF-8" ?>
<dds>
    <profiles xmlns="http://www.eprosima.com">
        <data_writer profile_name="cft_on_late_joiners_xml_profile">
            <propertiesPolicy>
                <properties>
                    <!-- Enable content filtering on late joiners -->
                    <property>
                        <name>fastdds.content_filtering_on_late_joiners</name>
                        <value>true</value>
                    </property>
                </properties>
            </propertiesPolicy>
        </data_writer>
    </profiles>
</dds>