Tomoya Fujita

@MiguelCompany @EduPonz any idea? this issue sounds like unreliable behavior. @robert-preissl this problem only happens with discovery server? what if we start application without fastdds discovery server?

@robert-preissl i really do not have any clue for this behavior right now. just one question, > running the same with cyclone dds (RMW_IMPLEMENTATION=rmw_cyclonedds_cpp) seems to be without any problems....

- Service Client ```bash [DEBUG] [1691565196.788552692] [rcl]: Client sending service request [INFO] [1691565196.790921418] [UdfInferenceService]: [0688780a-a38a-483d-884d-828d82d8b0c7] call async_send_request finish....... [DEBUG] [1691565196.790949868] [rcl]: Initializing wait set with '0' subscriptions, '2' guard conditions,...

related to https://github.com/ros2/rmw_fastrtps/issues/392, service discovery is the known issue. I confirmed that this can be observed with https://github.com/ros2/ros2/commit/036eb0b4e3d144227c30e787cfa5469d8eabf831.

The problem here is some participants cannot even find the service which is available and response the result as following. some service requesters are stuck in state just to wait...

CC: @iuhilnehc-ynos @MiguelCompany

Sorry, not much i can help w/o reproducible environment... > I'm not 100% sure that it is caused by the FastDDS middleware or its SHM transport To be sure for...

@ksuszka thanks for sharing the experience. Just FYI, several patches related SHM transport and data sharing is staging for next humble patch release. (https://github.com/ros2/ros2/pull/1484/files#diff-0b86fcc230a228fb210653f2069d07ee0ab117da02c6471640ae12327835ff4fL37-R37)

@Barry-Xu-2018 thanks for creating issue. as far as i tried on my environment, rolling https://github.com/ros2/ros2/commit/30e9231f04d6e971de4d9bcc3cc98733f8a89d23 still also has the problem. that is so unlikely but i did see the problem...

@MiguelCompany @EduPonz friendly ping.