Occasional SHM Transport issue

[quic-zhanlin]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

it can get the message normally

Current behavior

Processes on the same device cannot obtain messages, but processes across devices can obtain messages

Steps to reproduce

There are two ros node, one is publisher and the other one is subscriber.

Fast DDS version/commit

2.6.4-1

Platform/Architecture

Other. Please specify in Additional context section.

Transport layer

Shared Memory Transport (SHM)

Additional context

We use the Kirkstone version of Yocto and the Humble version of Meta ROS in LE

XML configuration file

default xml configure.

Relevant log output

we can see that the PDP and EDP has finish because the pub log show there has reader to receive the msg.
while in the sub side, it prints these log again and again.
Log:
1980-01-06 04:01:38.364 [RTPS_MSG_IN Info] (ID:548458952928) InfoDST message received, processing... -> Function processCDRMsg
1980-01-06 04:01:38.364 [RTPS_MSG_IN Info] (ID:548458952928) DST RTPSParticipant is now: 01.0f.2a.fc.7d.65.bc.c8.01.00.00.00 -> Function proc_Submsg_InfoDST
1980-01-06 04:01:38.364 [RTPS_MSG_IN Info] (ID:548458952928) Acknack Submsg received, processing... -> Function processCDRMsg
1980-01-06 04:01:38.365 [RTPS_MSG_IN Info] (ID:548458952928) InfoDST message received, processing... -> Function processCDRMsg
1980-01-06 04:01:38.365 [RTPS_MSG_IN Info] (ID:548458952928) DST RTPSParticipant is now: 01.0f.2a.fc.7d.65.bc.c8.01.00.00.00 -> Function proc_Submsg_InfoDST
1980-01-06 04:01:38.365 [RTPS_MSG_IN Info] (ID:548458952928) Acknack Submsg received, processing... -> Function processCDRMsg
1980-01-06 04:01:38.366 [RTPS_READER Info] Sending ACKNACK: 0: -> Function send_acknack
1980-01-06 04:01:38.366 [RTPS_MSG_OUT Info] (ID:548501223648) SharedMemTransport: 64 bytes to port 29423 -> Function send
1980-01-06 04:01:38.424 [RTPS_READER Info] Sending ACKNACK: 0: -> Function send_acknack
1980-01-06 04:01:38.424 [RTPS_MSG_OUT Info] (ID:548501223648) SharedMemTransport: 64 bytes to port 29412 -> Function send
1980-01-06 04:01:38.424 [RTPS_READER Info] Sending ACKNACK: 0: -> Function send_acknack
1980-01-06 04:01:38.424 [RTPS_MSG_OUT Info] (ID:548501223648) SharedMemTransport: 64 bytes to port 29424 -> Function send
1980-01-06 04:01:38.424 [RTPS_READER Info] Sending ACKNACK: 0: -> Function send_acknack
1980-01-06 04:01:38.424 [RTPS_MSG_OUT Info] (ID:548501223648) SharedMemTransport: 64 bytes to port 29412 -> Function send
1980-01-06 04:01:38.424 [RTPS_READER Info] Sending ACKNACK: 0: -> Function send_acknack
1980-01-06 04:01:38.424 [RTPS_MSG_OUT Info] (ID:548501223648) SharedMemTransport: 64 bytes to port 29412 -> Function send
1980-01-06 04:01:38.425 [RTPS_READER Info] Sending ACKNACK: 0: -> Function send_acknack
1980-01-06 04:01:38.425 [RTPS_MSG_OUT Info] (ID:548501223648) SharedMemTransport: 64 bytes to port 29424 -> Function send
1980-01-06 04:01:38.425 [RTPS_READER Info] Sending ACKNACK: 0: -> Function send_acknack
1980-01-06 04:01:38.425 [RTPS_MSG_OUT Info] (ID:548501223648) SharedMemTransport: 64 bytes to port 29424 -> Function send

Network traffic capture

No response

[Mario-DL]

Hi @quic-zhanlin

Thanks for using Fast DDS. According to our Platform support, custom Yocto images are not officially supported platforms, so I am moving this thread to the proper discussion forum.
Anyways, I would test with Fast DDS v2.6.9 and see if the issue persists.

[quic-zhanlin]

Hi @Mario-DL

Thanks for your reply.
Do you have any ideas in why the log print "[RTPS_READER Info] Sending ACKNACK: 0: -> Function send_acknack" so frequently.
BTW, Could you kindly help to tell me where we can add some log to get more info?

[JesusPoderoso]

Hi @quic-zhanlin, the default builtin transports are Shared-Memory and UDPv4, but Fast DDS prioritizes Shared-Memory over the UDPv4 transport when possible.

[paxifaer]

This is related to the design of fastdds. Its shm mechanism can be used to communicate with udp. Therefore, service discovery may be done through shm. But this should not affect normal work. You can modify your user-level code and comment out the places where shm communication is used.

[quic-zhanlin]

Yes, using UDP communication can avoid this problem, but using UDP transmission cannot ultimately solve this problem. Is the problem identified during the discovery phase based on logs and performance behavior？

[paxifaer]

Can you illustrate your requirements? 你说一下你想要什么，我帮你想想办法

[quic-zhanlin]

不好意思回复晚了，我们想看看这个问题的root cause，在哪能加log来进一步看这个问题