Hi All,
I'm working on a project using DDS Micro on PowerPC Linux device built from source. When I compile and run the HelloWorld programs they work as intended locally (i.e. Subscribers on teh device see Publishers on the device.)
If I then launch either "Admin Console" or "Monitor" on my PC (Windows or Linux) then it partially works, the Monitor sees the 2 processes as DomainParticipants but can't tell if they are Publishers or Subscribers and can't get any more infor. If I look at the output from the Publisher and Subsriber they are both full of these errors. As soon as I stop the Monitor/Admin Console these errors stop and they continue to comunicate:
[1442580548.629608999]ERROR: ModuleID=7 Errcode=713 X=1 E=0 T=1
undefined/DataReaderInterface.c:748/DDS_DataReaderInterface_receive: kind=2
[1442580548.629750999]ERROR: ModuleID=6 Errcode=22 X=1 E=0 T=1
undefined/RTPSInterface.c:3691/RTPS_Receiver_forward_upstream:
I have also compiled the Micro DDS and the HelloWorld example for my Linux laptop and get exactly the same results. I have also comiled several of teh HelloWorld examples and they all have the same issue.
I tried looking at the error code in the documentation but the erro code for module 7 doesn't go up that high (the second error is just because the first has happened)
the problem seems to be to do with this bit in the source:
if (DDS_BOOLEAN_TRUE != datareader->type_plugin->deserialize_data(
&datareader->stream,
sample->hst_sample._user_data,
plugin_data))
Also just to muddy the water I also have very odd behaviour whereby if I start a Pub on the device then a Sub on my laptop they both sit there doing nothing then as soon as I start a Sub on the device they both connect (most of the time) then I can disconnect the sub on the device and they run happily forever but If i stop either and try to restart they won't comunicate. Also If I start Monitor/Admin Console it sometimes trigger them to connect. Not sure if this extra bit is related to the orginal question but i rather suspect its a symptom of the above errors, this is the real issue I'm trying to fix but I think fixing the errors issue will make this work as intended. Also note the connection between the device and laptop is always there and working throughout (I am controlling the device via telnet so it has to be)
If any one has any ideas they would be greatly appreciated,
thanks in advance.
Hi Mark,
What you see is a bug in Micro that manifested itself with Connext Core 5.2.0. In Connext Core 5.2.0 the locator kind for the Connext Core shared memory transport changed from the value for UDPv6 (which was accepted, but is unsupported by Micro) to a vendor spceific value which is rejected by Micro. The bug is that Micro discards the entire discovery message from the Admin Console, in fact any Connect Core application that uses the shared memory transport, instead of discarding only the locator.
We are fixing this for the Micro 2.4.6 maintenance release which we are working on now.
There are two possible work-arounds until 2.4.6:
Option 1) Disable the shared memory transport in Connext Core 5.2.0.
This is can be done with something like this in the XML file for a Connext Core application in the participant_qos tag:
<transport_builtin>
<mask> DDS_TRANSPORTBUILTIN_UDPv4 </mask>
</transport_builtin>
Option 2) Patch Micro until we release 2.4.6. Assuming you are using the buildable source:
In the file <micro-source>/src/rtps/Cdr.c (RTPS_deserialize_ipv6_locator) about line 467, change the test to this: (== RTPS_LOCATOR_KIND_UDPv6 changes to != RTPS_LOCATOR_KIND_UDPv4)
if (NETIO_Address_get_kind((struct NETIO_Address*)loc) != RTPS_LOCATOR_KIND_UDPv4)
Change the else if test for RTPS_LOCATOR_KIND_UDPv4 on lin 474 to just an else branch and remove the current else branch on line 485.
While this is not our final solution it is sufficient to get around this problem until 2.4.6
regards,
tron