Failures on Windows about rmw_cyclonedds

[nuclearsandwich]

I wasn't able to reproduce this using the binary archive from https://ci.ros2.org/view/packaging/job/packaging_windows/1564/

When I did experience issues previously it was due to ros2 daemon running with a different rmw but @ivanpauno and I have discussed that offline and we're reasonably sure that's not the case here.

[sloretz]

I sort of wasn't able to reproduce this using https://ci.ros2.org/view/packaging/job/packaging_windows/1565/

The first time I ran the talker, nothing happend. There was no stdout from the talker at all. I started the listener and didn't see any output from that either. I investigated whether the talker prints anything (it does), and by the time I figured that out the talker and listener were communicating. I would guess it took a couple minutes before the talker started printing anything, and maybe a minute before the listener started. Now when I kill/restart the talker and listener the talker starts printing stuff immediately, and the talker/listener start communicating immediately.

[sloretz]

Ok this is weird, I was able to reproduce the same behavior again using demo_nodes_py. In the above comment, I was using demo_nodes_cpp. I did the same thing again with demo_nodes_py (started talker, waited, started listener), and saw the same behavior. The talker didn't print anything for about a minute, so I started the listener. Neither printed anything for ~15 seconds, then they started communicating. However, when I restart them they start communicating instantly.

[ivanpauno]

Thanks @nuclearsandwich @sloretz !

I also observed sometimes the behavior @shane is commenting (talker slow to start). But in my case, the listener never receives any message (after waiting many minutes). I tried many times in different fresh terminals.

I really don't know what is wrong in the environment I was testing.

Besides that, the failures in https://ci.ros2.org/view/nightly/job/nightly_win_extra_rmw_rel/543/#showFailuresLink should be investigated.

If nobody can reproduce this, we can close this one and open a new issue for the ci failures.

[nuclearsandwich]

I have seen Windows Defender try to scan every linked library via real-time protection or "protect me in real-time" cause slow executable startup time the first time around. I think we'd need to break out Wireshark to see whether the slow communication time is related to that or discovery issues.

[ivanpauno]

Closing as nobody else can reproduce the error.
Opened https://github.com/ros2/build_cop/issues/251 to follow-up in the CI failures.