|
RTI Connext C API
Version 6.1.2
|
DDS_LIVELINESS_CHANGED_STATUS More...
Data Fields | |
| DDS_Long | alive_count |
| The total count of currently alive DDS_DataWriter entities that write the DDS_Topic that this DDS_DataReader reads. More... | |
| DDS_Long | not_alive_count |
| The total count of currently not_alive DDS_DataWriter entities that write the DDS_Topic that this DDS_DataReader reads. More... | |
| DDS_Long | alive_count_change |
| The change in the alive_count since the last time the listener was called or the status was read. More... | |
| DDS_Long | not_alive_count_change |
| The change in the not_alive_count since the last time the listener was called or the status was read. More... | |
| DDS_InstanceHandle_t | last_publication_handle |
| This InstanceHandle can be used to look up which remote DDS_DataWriter was the last to cause this DataReader's status to change, using DDS_DataReader_get_matched_publication_data. More... | |
The DDS_DataReaderListener::on_liveliness_changed callback may be invoked for the following reasons:
The liveliness of any DDS_DataWriter matching this DataReader (as defined by the DDS_LivelinessQosPolicyKind setting) is lost.
A DataWriter's liveliness is recovered after being lost.
A new matching DataWriter has been discovered.
A matching DataWriter has been deleted.
A QoS Policy has changed such that a DataWriter that matched this DataReader before no longer matches (such as a change to the DDS_PartitionQosPolicy). In this case, RTI Connext will no longer keep track of the DataWriter's liveliness. Furthermore, consider two scenarios:
DataWriter was not alive when it and DataReader stopped matching: DDS_LivelinessChangedStatus::alive_count will remain the same (since the matching DataWriter was not alive) and DDS_LivelinessChangedStatus::not_alive_count will decrease (since there's one less not-alive matching DataWriter).
Note: There are several ways that a DataWriter and DataReader can become incompatible after the DataWriter has lost liveliness. For example, when the DDS_LivelinessQosPolicyKind is set to DDS_MANUAL_BY_PARTICIPANT_LIVELINESS_QOS, it is possible that the DataWriter has not asserted its liveliness in a timely manner, and then a QoS change occurs on the DataWriter or DataReader that makes the entities incompatible.
| DDS_Long DDS_LivelinessChangedStatus::alive_count |
The total count of currently alive DDS_DataWriter entities that write the DDS_Topic that this DDS_DataReader reads.
| DDS_Long DDS_LivelinessChangedStatus::not_alive_count |
The total count of currently not_alive DDS_DataWriter entities that write the DDS_Topic that this DDS_DataReader reads.
| DDS_Long DDS_LivelinessChangedStatus::alive_count_change |
The change in the alive_count since the last time the listener was called or the status was read.
| DDS_Long DDS_LivelinessChangedStatus::not_alive_count_change |
The change in the not_alive_count since the last time the listener was called or the status was read.
Note that a positive not_alive_count_change means one of the following:
The DomainParticipant containing the matched DataWriter has lost liveliness or has been deleted.
| DDS_InstanceHandle_t DDS_LivelinessChangedStatus::last_publication_handle |
This InstanceHandle can be used to look up which remote DDS_DataWriter was the last to cause this DataReader's status to change, using DDS_DataReader_get_matched_publication_data.
It's possible that the DataWriter has been purged from the discovery database. (See the "What is Discovery?" section of the User's Manual.) If so, the DDS_DataReader_get_matched_publication_data method will not be able to return information about the DataWriter. In this case, the only way to get information about the lost DataWriter is if you cached the information previously.