Restore dashing/eloquent behaviour of "service_is_available"

[eboasson]

This "mostly fixes" the lost service responses (#183, #74) by reinstating the check for a matching reader and writer in rmw_service_server_is_available that was accidentally deleted when the 1:1 mapping of nodes to participants was replaced by a 1:1 mapping of contexts to participants. This effectively restores dashing/eloquent behaviour.

It doesn't truly fix the problem and in the presence of packet loss the likelihood of failure remains significant. However, the workaround proposed in #187 is a bit controversial and this restoration of the old code at least should be non-controversial.

[hidmic]

LGTM!

[ivanpauno]

• Linux
• Linux-aarch64
• macOS
• Windows

[ivanpauno]

@hidmic can we merge this one already?

I think that no matter if we go ahead with #187 or not, merging this one first is a good idea.

[ivanpauno]

@hidmic friendly ping

[hidmic]

@ivanpauno agreed.

[hidmic]

@jacobperron ?

[jacobperron]

Have you investigated the failing test? I guess it's something that we don't normally test for, since it would typically run with rmw_fastrtps_cpp.

[hidmic]

@jacobperron it's a cppcheck error about macro configuration.

[jacobperron]

@hidmic I meant the jobs from ci.ros2.org: https://ci.ros2.org/job/ci_linux/10939/testReport/junit/(root)/rclcpp/test_subscription_topic_statistics_gtest_missing_result/

[hidmic]

I see. I have not. I'll check locally.

[ivanpauno]

It's happening in build.ros2.org too: http://build.ros2.org/view/Fci/job/Fci__nightly-cyclonedds_ubuntu_focal_amd64/128/testReport/junit/(root)/rclcpp/test_subscription_topic_statistics_gtest_missing_result/.

Seems unrelated to me

[hidmic]

It's happening in build.ros2.org too

Indeed. Fix incoming. In the meantime, let's merge.