Best Practices for having many Topics

6 posts / 0 new
Last post
Offline
Last seen: 6 hours 10 min ago
Joined: 11/23/2021
Posts: 3
Best Practices for having many Topics

Hi, so I have a couple of issues.

1. What is the best practice for using many topics? Do I put them all in one qos.xml? How should each application identify the topics (Using separate domain participant libraries/domain participants/publishers/datawriters)?

2. Currently I placed all my topics in one qos.xml. It seems that when I start up a Connector, all the other topics that are not used by the Conneector is also started up when I view in the Admin Console. Furthermore, when I create many Connectors, each using a different topic, there seems to be many of the same instances of Connectors created for each topic (Match Graph in Admin Console shows many Publishers::DataWriters with the same name linked to each topic). Having many of those instances seems to use up too much memory, resulting in my program getting Killed (testing with fewer instances does not cause it to be Killed).

3. Is there a simple way to create listeners that trigger a function using Connectors? Currently I am using separate threads/processes to listen to topics so that the main thread/process can do something else.

Thank you in advance.

Keywords:
Offline
Last seen: 3 days 21 hours ago
Joined: 10/22/2018
Posts: 76

Hey,

1. If for whatever reason you do not want to define all of the Topics in one XML file, Connector supports loading from multiple XML files. This explained here in the Connector documentation, and in the URL groups section of the Connext DDS User's Manual. This functionality was added in Connector v1.1.0. As a general practice it is best to keep the number of domain participants being used in a system to a minimum, since they are resource heavy entities.

2. If you add this snippet to your Subscriber QoS and Publisher QoS, the contained DataReaders and DataWriters will only be created when call get_input/get_output on them in Connector:

  <entity_factory>
    <autoenable_created_entities>false</autoenable_created_entities>
  </entity_factory>

This is required because the entire XML file is parsed when you create a Connector, and all of the entities are created at that point in time.

With respect to your question about having many DataWriters for each Topic, I would need to see your XML file to work out why that was happening.

3. Are you using Connector for Python or Connector for JavaScript? In the JavaScript Connector you can install an on_data_available listener (at either the DataReader level, or the DomainParticipant level). This is explained here in the documentation. If you are using Connector for Python there is no support for listeners.

Hope that helps,

Sam

Offline
Last seen: 6 hours 10 min ago
Joined: 11/23/2021
Posts: 3

Thank you so much for your reponse,

1. I'm okay with putting all topics in one XML file, just wasn't sure if that was good practice.

2. Having many of the same DataWriters for each Topic could be related to having the DataWriters enabled unnecessary, as a result for every Connector I create they parse the entire XML file and each time they enable a new set of DataWriters/DataReaders.. However, I am having issues with using the code snippet provided. The library is complaining that entity_factory is an unexpected tag. I included a snippet of how I added below, do advice if there are any misunderstandings.

<publisher name="MyPublisher">
  <entity_factory>
    <autoenable_created_entities>false</autoenable_created_entities>
  </entity_factory>
  <data_writer name="MyDataWriter" topic_ref="topic_1">
    <datawriter_qos name="MyQosWriter" base_name="MyLibrary::MyProfile"/>
  </data_writer>
</publisher>
 

3. Unfortunately I am using Connector for Python, looks like I have to stick with multiprocessing. I do have some new findings though: I am able to send messages from the main process but not from child processes. Is it supposed to work this way?

 

 

Offline
Last seen: 3 days 21 hours ago
Joined: 10/22/2018
Posts: 76

Hey,

So for the QoS snippet you must add it within the publisher_qos tag (and also for the subscriber_qos tag). Here is an example.

As for the threading question, what happens when you try to write from the child process? We have a section of the documentation on threading which maybe you haven't seen.

Offline
Last seen: 6 hours 10 min ago
Joined: 11/23/2021
Posts: 3

Hi,

After adding <entity_factory> to my XML, it seems all the topics are still initialised and appear on RTI Admin Console in the Domain. Eg. DDS Logical View > System > Domain > all topics listed (even though I wrote a program to create only one Connector)

I don't think the threading documentation is able to help me as I am doing multiprocessing rather than multithreading, furthermore the Connectors I use in each process is/will be unique hence I don't think locks are needed? Do correct me if I am wrong.

When I write from a Connector in the child process, nothing happens. Nothing shows up on the Admin Console and nothing is received by my Subscriber. However, I am able to send messages when I write from the main process.

Offline
Last seen: 3 days 21 hours ago
Joined: 10/22/2018
Posts: 76

Can you send me your XML file?

 

How are you creating the child process? Using fork()?

Can you increase the versbosity on the subscriber application so we can see the log? Here are instructions on how to increase verbosity in Connector.