This PR is more of a proof-of-concept than a concrete proposal.
If there is a broken ROS 2 daemon process or another completely unrelated TCP server listening on the corresponding XMLRPC port, it's possible for calls like is_daemon_running to hang for a VERY long time.
For example:
In one shell, start a simple TCP server on port 11511: nc -k -l 11511
In another shell, run ros2 daemon status
You can see the XMLRPC request on the server, but without a response, the call to ros2 daemon status will just sit there. I'm not sure how long it will go before the "global default" timeout will kick in, but I haven't waited long enough to see it.
This can be a particularly bad problem in this package's tests, many of which connect to and sometimes create and destroy daemon processes. It would be nice if those tests didn't hang.
Possible mitigation for problems like #610 and #737
This PR is more of a proof-of-concept than a concrete proposal.
If there is a broken ROS 2 daemon process or another completely unrelated TCP server listening on the corresponding XMLRPC port, it's possible for calls like
is_daemon_runningto hang for a VERY long time.For example:
nc -k -l 11511ros2 daemon statusYou can see the XMLRPC request on the server, but without a response, the call to
ros2 daemon statuswill just sit there. I'm not sure how long it will go before the "global default" timeout will kick in, but I haven't waited long enough to see it.This can be a particularly bad problem in this package's tests, many of which connect to and sometimes create and destroy daemon processes. It would be nice if those tests didn't hang.
Possible mitigation for problems like #610 and #737