I have been studying content filtered topics and read and query conditions and find it a bit difficult to really pinpoint the intention of using multiple read and query conditions instead of simply creating multiple content filtered topics subscriptions. The only rational that I can come up with is that (1) creating multiple content filtered topics with (2) different filters expressions on the same topic and (3) from the same subscriber, might allocate redundant resources in the middleware, given that datareaders are considered of possessing their own local cache of topic in which they access. Therefore using read and query conditions on top of existing subscriptions are less resource demanding? Is this correct?
The reason why I find content filtered topics more appealing than read and query conditions is due to the fact that listeners are notified whenever their filter expressions evaluate to true, contrary to explicitly demultiplexing waitsets and manually dispatching triggered conditions.
The difference between a ContentFilter and a Read/QueryCondition is mainly based on when it is applied: - a ContentFilter is applied on samples before they are inserted into the DataReader. - a Read/QueryCondition is applied on samples that have already been inserted into the DataReader.
So a Filter may prevent samples from being inserted into a DataReader, thus potentially saving resources in this DataReader. A Filter is typically used when the expression parameters are pretty fixed do not need to change over time. Changing a filter parameter could cause the current contents of the DataReader not to match the filter expression any longer. You would need to wait a full update round (i.e. a period of time in which all of the relevant instances are updated) before the contents of the DataReader reflect the new filter parameters. At most one content filter can be attached to a single DataReader.
A Read/QueryCondition can be used to locate a subset of all samples stored in a DataReader. They are typically used when expression parameters may change over time. Changing an expression parameter and re-executing the Read/QueryCondition immediately results in a new subset that reflects your expression parameters. Multiple Read/QueryConditions can be attached to a single DataReader.
In the example you mention, you compare having multiple contentfilters (and thus multiple DataReaders) with having one DataReader using multiple Read/QueryConditions. If the filter expressions are overlapping, it means the same sample might be referenced from multiple readers, thus introducing more overhead than when having the same sample referenced from just a single DataReader.
It is true that you cannot use a Listener to be notified of a sample entering the DataReader and matching your Read/QueryCondition. However, a Listener mechanism can easily be build by spawnig an extra thread and blocking it on the WaitSet. If then the WaitSet triggers, the thread may invoke any callback operation you registered to it.