wait for service in client example

[gerkey]

The test that uses this client example can fail if the server isn't yet up and ready to hear the client's request. In that situation, the client waits forever and the test times out, as we've seen with FastRTPS. This PR adds a wait_for_service() call that the client uses to delay its request until the time is right.

This function should not live here in the long term, but rather be improved and promoted into client API (ros2/rclcpp#201). But this is a decent place to park it for now.

[dirk-thomas]

Since the problem probably affects all of the service tests does it make sense to only patch it for this single one?

[gerkey]

• http://ci.ros2.org/job/ci_linux/1059/
• http://ci.ros2.org/job/ci_osx/869/
• http://ci.ros2.org/job/ci_windows/1125

[gerkey]

@dirk-thomas The right fix is to implement the wait_for_service call in the client library and use it everywhere, including here. My implementation isn't yet ready to be promoted in that way (we may need some changes to the rmw API), and I don't want to copy this code everywhere that services are called in our tests. If, before we address ros2/rclcpp#201, we see other failures caused by the same underlying problem, I'll look at factoring it out for reuse, at least within this package.

[wjwwood]

This is a fairly blanket error case, maybe you could either check the error message contents or at least print it out so that when there is an error that doesn't match what you expected you can see it in the log? That might break your example test though.

[wjwwood]

+1 The change makes sense to me. It's unfortunate that FastRTPS doesn't implement the solution I suggested to you 😢.

[gerkey]

This change made more tests fail on Linux and it didn't even build on Windows. Fun!

[gerkey]

Windows build fixed and same logic added to async client (it'll be removed from both examples once we resolve ros2/rclcpp#201). New CI:

• http://ci.ros2.org/job/ci_windows/1167/
• http://ci.ros2.org/job/ci_linux/1100/
• http://ci.ros2.org/job/ci_osx/885/

[gerkey]

CI shows only failures and warning that are unrelated to this change.

[gerkey]

@wjwwood You +1ed previously, but can you have a second look before I merge?

[wjwwood]

One issue here is that node->count_subscribers should never throw a C++ exception. This is actually a problem with the fast rtps implementation, but ideally it would catch the exception internally and convert it to a return code.

[wjwwood]

I should have said, it should never throw a C++ exception because it is a C function.

[gerkey]

The underlying function rmw_count_subscribers() is C (for fastrtps, it's hardcoded to return an error: https://github.com/eProsima/ROS-RMW-Fast-RTPS-cpp/blob/master/rmw_fastrtps_cpp/src/functions.cpp#L1793-L1801), but here I'm calling a C++ class method: https://github.com/ros2/rclcpp/blob/master/rclcpp/src/rclcpp/node.cpp#L317-L329.

[wjwwood]

Ah, my bad. Sorry for the noise 🔔.

[gerkey]

When the logic is fixed to actually require that > 0 subscribers are hooked up, the test fails for opensplice and both flavors of connext. I suspect that the problem is that, as @wjwwood previously suggested, you can't assume that services are implemented atop topics and check for subscribers to infer that a service server is up. This approach is a dead end.