Bug in waitset triggered event handling

[rookybird]

Is there an already existing issue for this?

• I have searched the existing issues

Expected behavior

I am trying to use waitset for data reception and I referenced wait_set example.
I am trying to use "liveliness_lost(), liveliness_changed(), subscription_matched(), and data_available()"
I have set the data reader and writer's qos:

rqos.liveliness().kind = AUTOMATIC_LIVELINESS_QOS;
rqos.liveliness().lease_duration = eprosima::fastrtps::Duration_t(0,800000000);

wqos.liveliness().kind = AUTOMATIC_LIVELINESS_QOS;
wqos.liveliness().lease_duration = eprosima::fastrtps::Duration_t(0,800000000);
wqos.liveliness().announcement_period = eprosima::fastrtps::Duration_t(0,100000000);

I expect

• "liveliness_lost" to be triggered when no data received within 800 ms.
• "liveliness_changed" to be triggered once when communication settled and once when no data received within 800 ms
• "subscription_matched" to be triggered once when corresponding data writer and reader are paired and ready for communication
• "data_available" to be triggered as soon as data arrived.

Current behavior

I found that

• "liveliness_lost()" never triggered

• "changed_statuses.is_active(StatusMask::liveliness_changed)" was called many many times when liveliness changed

• I found that "StatusMask::subscription_matched" was always true since first time match.

• "data_available" worked as expected

Steps to reproduce

My code structure is similar to the one in the tutorial except I create the data reader in the beginning.

If you are interested, you can take a look at my code. From line 177 - 317
VIF.zip

Fast DDS version/commit

I am using Fast DDS 2.7.1 on ubuntu 18

Platform/Architecture

Other. Please specify in Additional context section.

Transport layer

Default configuration, UDPv4 & SHM

Additional context

No response

XML configuration file

No response

Relevant log output

No response

Network traffic capture

No response

[MiguelCompany]

@rookybird We are about to release 2.7.2, which will mark the EOL for branch 2.7.x, but includes PR #3199, which might be related to the issue you are describing.

Could you check whether using 2.7.x fixes this issue?

[MiguelCompany]

@rookybird I've been looking at this in more detail.

"liveliness_lost" to be triggered when no data received within 800 ms.
"liveliness_lost()" never triggered

This status is on the DataWriter and has nothing to do with data reception. It will trigger, under certain configurations of the LIVELINESS QoS, when a call to either write or assert_liveliness is not done on the DataWriter within the lease_duration.

Since you are using AUTOMATIC_LIVELINESS_QOS, the participant will automatically assert the liveliness of the writer. Quoting from our documentation (emphasis mine):

The service takes the responsibility for renewing the leases at the required rates, as long as the local process where the participant is running and the link connecting it to remote participants exists, the entities within the remote participant will be considered alive. This kind is suitable for applications that only need to detect whether a remote application is still running.

For the expectation you have, you should use MANUAL_BY_TOPIC_LIVELINESS_QOS

"liveliness_changed" to be triggered once when communication settled and once when no data received within 800 ms

The same applies here: using MANUAL_BY_TOPIC_LIVELINESS_QOS would give the expected results

"subscription_matched" to be triggered once when corresponding data writer and reader are paired and ready for communication
I found that "StatusMask::subscription_matched" was always true since first time match.

The status is reset after calling get_subscription_matched_status. If you never call this method, StatusMask::subscription_matched will remain true.

"data_available" to be triggered as soon as data arrived.
"data_available" worked as expected

Fine!

[rookybird]

@rookybird I've been looking at this in more detail.

"liveliness_lost" to be triggered when no data received within 800 ms.
"liveliness_lost()" never triggered

This status is on the DataWriter and has nothing to do with data reception. It will trigger, under certain configurations of the LIVELINESS QoS, when a call to either write or assert_liveliness is not done on the DataWriter within the lease_duration.

Since you are using AUTOMATIC_LIVELINESS_QOS, the participant will automatically assert the liveliness of the writer. Quoting from our documentation (emphasis mine):

The service takes the responsibility for renewing the leases at the required rates, as long as the local process where the participant is running and the link connecting it to remote participants exists, the entities within the remote participant will be considered alive. This kind is suitable for applications that only need to detect whether a remote application is still running.

For the expectation you have, you should use MANUAL_BY_TOPIC_LIVELINESS_QOS

"liveliness_changed" to be triggered once when communication settled and once when no data received within 800 ms

The same applies here: using MANUAL_BY_TOPIC_LIVELINESS_QOS would give the expected results

"subscription_matched" to be triggered once when corresponding data writer and reader are paired and ready for communication
I found that "StatusMask::subscription_matched" was always true since first time match.

The status is reset after calling get_subscription_matched_status. If you never call this method, StatusMask::subscription_matched will remain true.

"data_available" to be triggered as soon as data arrived.
"data_available" worked as expected

Fine!

Thank you so much! Your explanation is thorough and clear. I appreciate your help: )