How can the creation of a DomainParticipant fail?
Note: Applies to RTI Connext 4.x and above
Problem
You are trying to create a new DomainParticipant and see error messages about an invalid port and/or a failure to create a receive resource. For instance:
[D0001|ENABLE]NDDS_Transport_UDPv4_Socket_bindWithIp:0X1CF2 in use
[D0001|ENABLE]NDDS_Transport_UDPv4_SocketFactory_create_receive_socket:invalid port 7410
[D0001|ENABLE]NDDS_Transport_UDPv4_create_recvresource_rrEA:!create socket
Cause
The specific messages you see will vary based on the transports over which the new DomainParticipant is trying to communicate. If it is trying to communicate over an IP transport, it is probably trying to bind to one or more unicast ports already in use (as in the above example). This problem will only arise if another application (or DomainParticipant within the same application) is currently using the port(s) in question.
If it is using a shared memory transport, however, the culprit may be an application that failed to exit cleanly, orphaning a shared memory region and leaving it inaccessible to the new DomainParticipant. (The above is only a problem in RTI DDS 4.0g. Reuse of shared memory handles is fixed in RTI DDS 4.0h and later.)
The most common cause of this problem is an incorrectly set participant index. The port numbers (in the case of an IP transport) or shared memory handle (in the case of a shared memory transport) are calculated based on a DomainParticipant's domain ID and participant index.
If you have only a single DomainParticipant on a given node, there is no need to set the participant index. However, if there are multiple DomainParticipants on the same computer, each one must have a unique participant index. The participant_index
is a field in the DomainParticipant’s Discovery QosPolicy.
- In RTI DDS 4.0, the user is responsible for ensuring each DomainParticipant is created with a unique
participant_index
. - In RTI DDS 4.1 and later, the participant index is assigned automatically by default.