When I try to start an RTI service on a machine with no active network connections, I get the following error:
[CREATE Participant]COMMENDActiveFacade_new:!precondition [CREATE Participant]PRESParticipant_new:!create facade [CREATE Participant]DDS_DomainParticipantPresentation_initialize:!create participant core [CREATE Participant]DDS_DomainParticipant_createI:!create presentation participant [CREATE Participant]DDS_DomainParticipantFactory_create_participant_disabledI:!create participant DDSDomainParticipant_impl::create_disabledI:!create participant DDSDomainParticipant_impl::createI:!create participant DomainParticipantFactory_impl::create_participant():!create failure creating participant create_participant error
This is using ndds 5.1.0 on CentOS 7, and can be reproduced using rtiddsping, or any other tool that tries to create a domain participant. It occurs even if the transport is limited to shared memory, but the error goes away when the network link is restored. I've done a little debugging and found a couple things:
- This only happens when there is no interface on the system with an IP address. If I create a dummy interface with a static IP, the problem goes away.
- After the network cable is unplugged, there is a brief period where creating a domain participant still works. This corresponds to the period after the link is lost, but before the IP address is removed from the interface.
- The programs work fine if they were started before the link goes away. After the connection is lost, the publishers keep on publishing and the subscribers keep on getting data, even with our QoS restricted to use UDP-only. Only programs that try to create a new domain participant seem effected at all.
I've found this thread detailing the same problem: https://community.rti.com/forum-topic/create-participant-error-intel-nuc-x64. The only solutions were to create a network link (which we can not always guarantee), or to use shared memory (which our testing shows doesn't solve the problem).
I appreciate any help in tracking this one down. If it's fixed in a newer version, I'm happy to try and upgrade, but I'd like confirmation before starting the process.
Thanks!
Until recently Connext DDS did not support changing IP addresses or adding new interfaces. Bringing interfaces up and down was only partially supported. In addition, it was required to have at least one IP address to create a participant. An address was required disregard of the transports set even when using only shared memory.
What you describe is completely consistent with how 5.1.0 or 5.2.0 work. The good news is that Connext DDS is now fully robust to IP address and interface changes. All locator changes are detected and propagated to other participants via discovery. If a new IP address or a new interface becomes available it will be immediately detected and used. It is now possible to start a participant with no addresses or interfaces and creating a participant that uses only shared memory no longer requires an IP address.
All these nice features will be part of the next general access release. However we have a fully functional beta that is already deployed by some customers quite successfully. You probably should contact your account team. They can provide you with an early access release.
Thanks for the response, that's very helpful. I'll look into getting access to that beta.
fmmaroto,
What version contains the changes you mentioned? Thanks.
Version 5.2.2. A newer suitable version, 5.2.5, will be available in September. Versions 5.2.3 and 5.2.4 belong to other branches and do not have these improvements.
Fernando,
Any udpate on when 5.2.5 will be released? Thanks.
Yes, 5.2.5 has been released.