Hi,
I have an application built on Connext Micro 2.4.1 that communicates with other DDS applications. It fails to discover a reliable remote writer that should match its own reliable reader. When debugging the code, it seems that the remote writer is seen as if it were in best effort, and then the matching fails. In the same time RTI Analyzer succeeds in discovering both the reliable writer and the reliable reader, and concludes they match.
Does anyone has already observed this behavior?
Best regards.
Jean-François
Hi Jean-François,
Is the reliable remote writer that your Connext Micro 2.4.1 application fails to discover also from a Connext Micro 2.4.1 application?
Is your Connext Micro 2.4.1 application using static endpoint discovery (DPSE)? If so, check that the remote publication and subscription assertions are using the correct QoS, specifically the correct ReliabilityQos kind.
Regards,
Edward
Hi Edward,
In my case, the remote application is built on an OpenSplice implementation of DDS.
When I test my micro application with a remote application under Connext, the discovery works correctly. When I replace my micro application with a connext application (e.g. RTI Analyzer) the remote reliable writer under OpenSplice is also correctly discovered.
I uses the dynamic discovery (DPDE).
Best regards.
Jean-François
Hi,
After investigations, the matching succeeds with Connext Micro if the remote reliable writer in the Opensplice application is configured with max_blocking_time = 0.
If the remote application is based on Connext Professionnal, this condition seems to not be mandatory.
The Connext Micro documentation explains that max_blocking_time is not supported by Micro, but I don't understand how it may have an impact on the matching during the discovery phase.
Best regards.
Jean-François