add_two_ints_client doesn't respond in python on Windows about rclpy HOT 12 CLOSED

Note that I believe the tracebacks on shutdown are related to #95 so not exploring here.

from rclpy.

This also effects ros2 service call that also just hangs until Ctrl-Cd

C:\dev\ros2>ros2 service call /add_two_ints example_interfaces/AddTwoInts "{a: 2, b: 3}"
requester: making request: example_interfaces.srv.AddTwoInts_Request(a=2, b=3)

Exception ignored in: <bound method Node.__del__ of <rclpy.node.Node object at 0x0000008FB1C4F4A8>>
Traceback (most recent call last):
  File "C:\dev\ros2\install\Lib\site-packages\rclpy\node.py", line 255, in __del__
    self.destroy_node()
  File "C:\dev\ros2\install\Lib\site-packages\rclpy\node.py", line 224, in destroy_node
    'client', cli.client_handle, self.handle)
RuntimeError: Failed to fini 'client': rcl node is invalid, rcl instance id does not match, at C:\dev\ros2\src\ros2\rcl\rcl\src\rcl\node.c:346
Failed to fini 'client': rcl node is invalid, rcl instance id does not match, at C:\dev\ros2\src\ros2\rcl\rcl\src\rcl\node.c:346

from rclpy.

Note that I believe the tracebacks on shutdown are related to #95 so not exploring here.

The error you see on shutdown looks more like ros2/examples#175. Please try the same patch here.

from rclpy.

from rclpy.

I tried to run the executables you mentioned (add_two_ints_server, add_two_ints_client, add_two_ints_client_async (all in Python)) with Connext as well as FastRTPS and all of them worked fine for me. I used a from-source build from on of the Jenkins nodes.

Please try to reproduce the problem from a fresh build and provide more information.

from rclpy.

With a pull and rebuild this morning I cannot reproduce. @Kukanani If you can't reproduce either please close.

from rclpy.

Since we already have three "not reproducible" responses I will close this directly.

from rclpy.

I've done quite a bit more debugging on this. It appears to be the cross platform support. How much do we want to try to work on this for the beta? The only major issue within a platform is RTI python server - python client

RTI cpp add_two_ints_server

https://gist.github.com/tfoote/3ed7f4781b986c1a663b0233c41e7c96

RTI service call works
RTI cpp client works
RTI py client hangs

FRTPS service call works ~3 of 5 times
FRTPS cpp client works
FRTPS py client hangs most of the time

RTI py add_two_ints server

https://gist.github.com/tfoote/aecc5cbd359c5a839d5e317b94b212c5

FRTPS service call 50%
FRTPS python client 50%
FRTPS cpp client flakey

RTI service call works relatively well (maybe missing wait for service/retry)
RTI cpp client <50% success
RTI python client 5+ failures in a row

Other...

RTI Python server quit after 2 rounds on RTI cpp client and FastRTPS cpp client https://gist.github.com/tfoote/aecc5cbd359c5a839d5e317b94b212c5#file-fastrtps-cpp-client-server-oddity
Python client doesn't appear to have a wait for service
Running RTI Montior gives tracebacks for both publisher and subscriber. I think this is just shmen turned off: https://gist.github.com/tfoote/af5570a7df5a9ea839fa7daf02554e17 The monitor seems to have no data.

FRTPS cpp server

https://gist.github.com/tfoote/5810bbc1a4f88f14cda29cd8094405b1

FRTPS service call good
FRTPS cpp client good
FRTPS py client good

RTI service call nothing
RTI python client nothing
RTI cpp client nothing

FRTPS py server

https://gist.github.com/tfoote/9145d1285e3a9a9f36b15f9228ed2ecd

FRTPS service call good
FRTPS cpp client good
FRTPS py client good

RTI service call (request goes through, but reply doesn't come back)
RTI cpp client same as above

from rclpy.

cross platform support

The right term for this testing is "cross vendor". "Cross platform" refers to e.g. testing a server on Linux using a client on Windows.

The gist output contains the following two pieces repeatedly:

• The Python client making three requests in a row
• Errors when existing the executable

Are you sure that you are using the latest version for testing? The first one is behavior which was changed recently to only request once. Also (some of) the exit problems have been fixed in the last days.

Can you please compare the exact hashes of your code with the latest default branches and make sure that you have rebuild everything cleanly.

from rclpy.

The instructions at https://github.com/ros2/ros2/wiki/Maintaining-a-Source-Checkout didn't have vcs pull so I found I had the changes from the last day in the repo. I've updated the instructions and will retest.

from rclpy.

I tested this with a fresh build (same VM as @tfoote )

Fastrtps every combination of server and client (cpp/python) works fine
Connext:

• cpp server, cpp client/client_async: OK
• cpp server, py client_async: OK
• cpp server, py client: hangs, server never receives request
• py server, py client_async: OK
• py server, py client: hangs, server never receives request
• py server, cpp client/client_async: OK

So it looks to be an issue with the Python client on connext

from rclpy.

This looked to be a timing issue related to machine performance that's why it was showing up only in the VMs. Sleep time is arbitrary though so this is a temporary fix, we need a Python version of "wait_for_service" to actually fix the issue

from rclpy.