Inconsistent pub/sub matching at different participants

6 posts / 0 new
Last post
Offline
Last seen: 11 years 6 months ago
Joined: 03/18/2013
Posts: 5
Inconsistent pub/sub matching at different participants

I'm running NDDS 4.0i under Red Hawk on a Blade. I have two applications that are supposed to talk to each other via a simple one-topic protocol. My problem is that the applications may be very slow (tens of seconds) to recognize a publication_match or subscription_match. I may have one application that has matched both pub/sub and the other neither or only one of them.

Any ideas?

Organization:
rose's picture
Offline
Last seen: 3 years 2 months ago
Joined: 08/22/2011
Posts: 148

Hello stmarple,

I know that we made discovery performance improvements in the 4.2x era, but those mostly affected systems that were much larger.  

Is this discovery over shared memory or over the network?  Do both of your applications have consistent initial peers and transport settings?  

Thank you!

Rose Wahlin

Gerardo Pardo's picture
Offline
Last seen: 4 months 6 days ago
Joined: 06/02/2010
Posts: 602

Hello

You may want to take a look at the this slow discovery forum thread. Specifically the response titled "Re: Discovery Time-- Potential Solution". It contains an example XML configuration thets the DomainParticipantQoS to improve discovery time.  RTI DDS 4.0i  did not support the use of XML to define QoS and we have made many improvements since then as Rose mentioned. However, while I am not completely sure, I think most of the settings that are defined in that "fast_dicovery" profile within that XML file  are things that you can also configure directly using the C/C++ API my modifying the DomainParticipantQoS that you pass to the create_participant() operation.

Regards,

Gerardo

 

Offline
Last seen: 11 years 6 months ago
Joined: 03/18/2013
Posts: 5

Rose, I'm communicating via network and using the default QoS settings. I should know exactly what you are talking about wrt initial peers and transport settings, but I don't. We are porting this application from a Sun system and it didn't really work there, though it was better. If I have one application up and then start the other one, the first one usually connects right away - within a second. This works regardless of which one starts first. If I kill and restart the second app, I can eventually get them both happy. I'm using a "launcher" to kick them off, so they typically start at the "same" time. So, I guess the problem is in the area of discovering with applications that are already running

A little more information: I am currently concerned only with one topic and its readers and writers as I'm trying to get my two simulation drivers working together. Once that is good, I will be using one of the simulation components to drive a target system with something on the order of 25 topics. Those readers and writers are being created now, but there isn't anything to match up with yet.

Thanks for the help thus far.

 

rose's picture
Offline
Last seen: 3 years 2 months ago
Joined: 08/22/2011
Posts: 148

Ah, I have an idea of what might be wrong, if this is only happening after a restart of one of the applications:

I suspect that the application that is restarted is given the same GUID that it had before, which causes the new application to not realize this is a new, restarted application.  We have a solution that talks about this.  It specifies that this happens on VxWorks, but this can happen on other platforms if the process ID is being recycled when you shut down your application and restart. 

http://community.rti.com/kb/why-my-vxworks-application-unable-discover-other-rti-connext-applications-after-restart

Thank you!

Rose

Offline
Last seen: 11 years 6 months ago
Joined: 03/18/2013
Posts: 5

I'm off on travel for the next week, but I'll give this a go when I get back to the lab. It looks very promising.

Thanks again!