LIVELINESS
-
The LIVELINESS policy applies to the topic, data reader, and data writer entities via the
liveliness
member of their respective QoS structures. Setting this policy on a topic means it is in effect for all data readers and data writers on that topic. Below is the IDL related to the liveliness QoS policy:
enum LivelinessQosPolicyKind {
AUTOMATIC_LIVELINESS_QOS,
MANUAL_BY_PARTICIPANT_LIVELINESS_QOS,
MANUAL_BY_TOPIC_LIVELINESS_QOS
};
struct LivelinessQosPolicy {
LivelinessQosPolicyKind kind;
Duration_t lease_duration;
};
-
The LIVELINESS policy controls when and how the service determines whether participants are alive, meaning they are still reachable and active. The
kind
member setting indicates whether liveliness is asserted automatically by the service or manually by the specified entity. A setting of
AUTOMATIC_LIVELINESS_QOS
means that the service will send a liveliness indication if the participant has not sent any network traffic for the
lease_duration
. The
MANUAL_BY_PARTICIPANT_LIVELINESS_QOS
or
MANUAL_BY_TOPIC_LIVELINESS_QOS
setting means the specified entity (data writer for the “by topic” setting or domain participant for the “by participant” setting) must either write a sample or manually assert its liveliness within a specified heartbeat interval. The desired heartbeat interval is specified by the
lease_duration
member. The default lease duration is a pre-defined infinite value, which disables any liveliness testing.
-
To manually assert liveliness without publishing a sample, the application must call the
assert_liveliness()
operation on the data writer (for the “by topic” setting) or on the domain participant (for the “by participant” setting) within the specified heartbeat interval.
-
Data writers specify (
offer
) their own liveliness criteria and data readers specify (
request
) the desired liveliness of their writers. Writers that are not heard from within the lease duration (either by writing a sample or by asserting liveliness) cause a change in the
LIVELINESS_CHANGED_STATUS
communication status and notification to the application (e.g., by calling the data reader listener’s
on_liveliness_changed()
callback operation or by signaling any related wait sets).
-
This policy is considered during the establishment of associations between data writers and data readers. The value of both sides of the association must be compatible in order for an association to be established. Compatibility is determined by comparing the data reader’s requested liveliness with the data writer’s offered liveliness. Both the kind of liveliness (automatic, manual by topic, manual by participant) and the value of the lease duration are considered in determining compatibility. The writer’s offered kind of liveliness must be greater than or equal to the reader’s requested kind of liveliness. The liveliness kind values are ordered as follows:
MANUAL_BY_TOPIC_LIVELINESS_QOS > MANUAL_BY_PARTICIPANT_LIVELINESS_QOS > AUTOMATIC_LIVELINESS_QOS
-
In addition, the writer’s offered lease duration must be less than or equal to the reader’s requested lease duration. Both of these conditions must be met for the offered and requested liveliness policy settings to be considered compatible and the association established.