Open thomas-moulard opened 5 years ago
For fastrtps
<-> connext
cases, we found Connext could be too restrictive about part of the guidPrefix. We solved the error output problems on eProsima/Fast-RTPS#353, that has just been merged on master.
For fastrtps
<-> opensplice
cases, it has been reported on eProsima/Fast-RTPS#142. Fast-RTPS does not yet support key-only data submessages. Opensplice sends key-only data messages to inform its endpoints dissapeared.
For fastrtps
<-> opensplice
cases, this has been solved by eProsima/Fast-RTPS#371, which will be included on release 1.7.1 (eProsima/Fast-RTPS#393).
Bug report
Required Info:
fastrtps
->opensplice
When terminating the listener node by pressing CTRL+C, some errors appear in the publisher node.
No error appear if the publisher node terminates first.
fastrtps
->connext
When terminating the talker or listener node, some log messages appear in the listener node.
Terminating the talker or listener first does not make any difference. Similar output is always printed out in the listener node.
opensplice
->fastrtps
When killing the
opensplice
talker first, thefastrtps
node prints out the same warnings than forfastrtps
->opensplice
. In either case, thefastrtps
node prints out errors while theopensplice
node terminates quietly.opensplice
->connext
Sporadically, the warning message "unique topic attempted to be added twice, ignoring" when starting the node.
connext
->fastrtps
The
connext
talker node is printing out the same message "Could not remove remote endpoint" than thefastrtps
->connext
scenario. In this case, thetalker
prints out the error message.The error message is printed out independently of whether the talker or listener is terminated first.
connext
->opensplice
Talker prints out from time to times:
Behavior seems identical to
opensplice
->connext
scenario.Similar behavior can be observed with
demo_nodes_py
nodes.