What can cause publishers and subsribers to not discover each other?

4 posts / 0 new
Last post
Offline
Last seen: 3 years 8 months ago
Joined: 03/09/2016
Posts: 6
What can cause publishers and subsribers to not discover each other?

Solved: See description below original post

I am having difficulty getting a publisher and subscriber to discover each other. I have intermittently had success, but I cannot determine what causes the success.

The publisher/writer and subscriber/reader are running on the same host. They are using the same QoS profile. They have the same domain id, topic, and type. I have confirmed all of this through rtiddsspy, which has no problem seeing the writer and reader. The publisher starts long before (minimum 10s of seconds) before any subscriber would ever come to life. The subscriber comes up successfully, but I never see the on_subscription_matched callback from my listener, which I have configured with DDS_STATUS_MASK_ALL. The QoS profile I am using uses the reliable reliability. I've also tried some other QoS profiles that have heartbeats built in to see if that would affect discovery. Is there anything else I need to do to make either side discoverable? Is there anything else you would suggest I check?


Thanks!

----------------------------------------------------------------

It turns out the deployment framework I'm using runs a cleanup script at startup. This cleanup script explicitly removes any DDS related shared memory segments. I'm changing up the order that my entities are created to work around this.

 

jwillemsen's picture
Offline
Last seen: 4 days 10 hours ago
Joined: 09/24/2013
Posts: 53

Have you double checked that the topic data type on both side match? The CCK does make any unbounded type a bounded type which could result in different types on both sides.

Offline
Last seen: 3 years 8 months ago
Joined: 03/09/2016
Posts: 6

I am fairly certain that the types on both sides match. The IDL used to generate the classes has bounds on all types that would have them. The writer is running from a Java program, and the reader is spawned from a C++ application. I ran RTI Admin Console with only the writer (Java app) active. I am able to see my topic on my domain ID, but it does warn me that the topic is a Reader-only topic. This seems bad given that rtiddsspy sees that there is a writer on that topic. RTI Admin console is only picking up the subscriber created by rtiddsspy.

If I run my Java application without rtiddsspy running, Admin Console is able to see the writer, but it does not discover the reader that the C++ application spawns. Is there any configuring I need to do to Admin Console to get it to discover entities automatically the way rtiddsspy does?


Some additional information: If I start a second instance of the Java application, my C++ application (the reader) successfully discovers the Java app's data writer. This leads me to believe that it's possible the first instance's data writer is being removed. I have a feeling this is due to some cleanup that the C++ application does at startup. I'll report back on what I find out.

jwillemsen's picture
Offline
Last seen: 4 days 10 hours ago
Joined: 09/24/2013
Posts: 53

Great to hear that it works now