rmw_fastrtps: No callback when AUTOMATIC liveliness is lost

Bug report

Required Info:

Operating System:
- Ubuntu 20.04 AMD64 & ARM64
Installation type:
- Binaries and from source
Version or commit hash:
- 1.0.0
Client library (if applicable):
- rclcpp & rclpy

Steps to reproduce issue

Try out the liveliness QoS demo using rmw_fastrtps_cpp . Default liveliness policy is already AUTOMATIC, but you may enforce it using the --policy option:

ros2 run quality_of_service_demo_py liveliness 1000 --kill-publisher-after 2000 --policy AUTOMATIC

Expected behavior

Liveliness change events are received and printed on screen.

Actual behavior

No liveliness change event is reported.

Additional information

The talker node in this demo is explicitly destroyed after some time. This issue does not show itself when using other RMW implementations like CycloneDDS, so I suspect that either the underlying DDS data writer is not getting destroyed or Fast-RTPS keeps asserting liveliness even after the DDS data writer is gone.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 18 (13 by maintainers)

Most upvoted comments

Found the issue with rclpy, but incidentally, a fix was merged 15 minutes ago (see https://github.com/ros2/rclpy/pull/603). I can confirm this is no longer an issue for none of the current RMW implementations. Thanks @eboasson @MiguelCompany !

hidmic on Jul 16, 2020

the only test that fails with rmw_cyclonedds_cpp (locally on my mac) is the deadline one and with that one, it really is the test that is broken: if there is no publisher, there is no instance and no deadline missed

@eboasson there is a publisher being instantiated. Nonetheless, I’d intuitively expect a subscriber with a given deadline QoS to complain if that deadline is missed regardless of ongoing publications or even publisher existence.

If I’m not mistaken, there is no publisher in the “test_deadline_no_publisher” test: while it does instantiate a QosTestPublisher, the constructor does next to nothing, leaving the creation of the publisher until later (setup_start).

Not generating deadline missed notifications if there is no instance is the way it is defined in the DDS spec, and I do think it is the right choice: in the DDS data model, there are keys identifying instances and deadline misses are tied to instances (where it actually informs you for which instance a deadline was missed). Naturally you don’t want these notifications for all instances that might come into existence in the future.

The case where there are no keys (which ROS 2 uses) is treated by the spec as the limit case where there is at most 1 instance, and so also requires the presence of data. I happen to agree with that choice, but one could perfectly well argue that in that case there should be no concept of an instance. Doing that breaks various other things through nasty interactions, for example, the case of a transient/persistent topic: without an instance, you can’t dispose data, without disposing data, you can’t get rid of transient/persistent data. Of course one can work around such details by adding special cases, but there are too many special cases in the specs already …

The other issue with generating deadline missed notifications without data being present, is that it is not unusual for a system to take a fair amount of time to initialise and then run at a sustained high rate. If you’d use a deadline that makes sense for the update rate, you’d be getting spurious deadline missed notifications during initialisation. Of course you could ignore those, or (in the DDS interface anyway) start with the notifications disabled, enabling them when the system becomes operational, but that has its own donwsides.

The usual OMG solution to such a problem is to make the behaviour configurable, but if you ask me, there are too many QoS settings as it is …

eboasson on Jul 16, 2020