Multiple Content Filters on One Topic

3 posts / 0 new
Last post
Last seen: 3 years 3 months ago
Joined: 12/08/2020
Posts: 2
Multiple Content Filters on One Topic


I'm hoping someone can help with this as I'm struggling to find an answer.

I'm using  RTI Connext 6.0.0 Modern C++ API. 

I have (inherited)  an application that has 15 readers of the same topic.

  • Each reader is in a thread
  • Each reader has a content filter, with the same fields but different parameter values.
  • Each reader is in it's own domain particiant, even though they are in the same domain.
  • Each of the readers uses the same topic name, but a different content filter topcic name; e.g. if the topic name is "TopicA" then the content filter topic is "TopicA_nnn" where nnn is a value 1 to 15.

When I change this so that it's using the same domain participant for each reader the code segfaults when creating the topics.

So my question is... can I have multiple instances of the topic with different content filters, in the same domain participant? and if I can is there somethign specific I have to do to get that to work / has someone got a small example?

I'm aware that I could have one content filter and then farm the data out to the threads in some manner, but I'm hoping there's a better solution. 

Thanks, Jon 

Howard's picture
Last seen: 2 days 13 hours ago
Joined: 11/29/2012
Posts: 567

Hi Jon,

The problem that you're having is probably create_topic() returned NULL when you tried to create a topic with a name of a topic that was already created in the same DomainParticipant.

In a single DomainParticipant, different topics must be created with unique other words, a specific topic can only be created once.  Not sure why your code would crash, but I suspect that it's because it didn't check if create_topic() succeeded or not.

In any case, you can use the same topic object to create multiple DataReaders...although that's an unusual design.  In your case, you can use the same topic object to create different content-filtered topic objects...which then are each used to create a DataReader.


But your instinct of using a single DomainParticipant in your application is correct.  Generally, a single DomainParticipant per DDS Domain is needed by an application.  DomainParticipants are heavy weight objects that allocate memory, sockets, semaphores, threads, etc., as well as each DomainParticipant will participate in on-the-wire discovery, so 15 DomainParticipants....15^2 times more discovery traffic...discovery takes place directly between every DomainParticipant in a domain.

Last seen: 3 years 3 months ago
Joined: 12/08/2020
Posts: 2


Thanks. That info has solved it.