#include <managed_infrastructure.h>
Static Public Member Functions | |
static System::String^ | get_livelines_qos_policy_name () |
Stringified human-readable name for DDS::LivelinessQosPolicy. | |
Public Attributes | |
LivelinessQosPolicyKind | kind |
The kind of liveliness desired. | |
Duration_t | lease_duration |
The duration within which a DDS::Entity must be asserted, or else it is assumed to be not alive. |
Liveliness must be asserted at least once every lease_duration
otherwise RTI Data Distribution Service will assume the corresponding DDS::Entity or is no longer alive.
The liveliness status of a DDS::Entity is used to maintain instance ownership in combination with the setting of the OWNERSHIP policy. The application is also informed via DDS::Listener when an DDS::Entity is no longer alive.
A DDS::DataReader requests that liveliness of writers is maintained by the requested means and loss of liveliness is detected with delay not to exceed the lease_duration
.
A DDS::DataWriter commits to signalling its liveliness using the stated means at intervals not to exceed the lease_duration
.
Listeners are used to notify a DDS::DataReader of loss of liveliness and DDS::DataWriter of violations to the liveliness contract. The on_liveliness_lost() callback is only called once, after the first time the lease_duration
is exceeded (when the DDS::DataWriter first loses liveliness).
This QoS policy can be used during system integration to ensure that applications have been coded to meet design specifications. It can also be used during run time to detect when systems are performing outside of design specifications. Receiving applications can take appropriate actions in response to disconnected DataWriters.
This policy has several settings to support both data types that are updated periodically as well as those that are changed sporadically. It also allows customisation for different application requirements in terms of the kinds of failures that will be detected by the liveliness mechanism.
The DDS::LivelinessQosPolicyKind::AUTOMATIC_LIVELINESS_QOS liveliness setting is most appropriate for applications that only need to detect failures at the process-level, but not application-logic failures within a process. RTI Data Distribution Service takes responsibility for renewing the leases at the required rates and thus, as long as the local process where a DDS::DomainParticipant is running and the link connecting it to remote participants remains connected, the entities within the DDS::DomainParticipant will be considered alive. This requires the lowest overhead.
The manual settings (DDS::LivelinessQosPolicyKind::MANUAL_BY_PARTICIPANT_LIVELINESS_QOS, DDS::LivelinessQosPolicyKind::MANUAL_BY_TOPIC_LIVELINESS_QOS) require the application on the publishing side to periodically assert the liveliness before the lease expires to indicate the corresponding DDS::Entity is still alive. The action can be explicit by calling the DDS::DataWriter::assert_liveliness operation or implicit by writing some data.
The two possible manual settings control the granularity at which the application must assert liveliness.
lease_duration
. This ensures that the value of the DDS::LivelinessChangedStatus is updated at least once during each lease_duration
and the related Listeners and DDS::WaitSet s are notified within a lease_duration
from the time the LIVELINESS changed.
lease_duration
<= requested lease_duration
evaluates to true. The kind of liveliness desired.
[default] DDS::LivelinessQosPolicyKind::AUTOMATIC_LIVELINESS_QOS
The duration within which a DDS::Entity must be asserted, or else it is assumed to be not alive.
[default] DDS::Duration_t::DURATION_INFINITE
[range] [0,1 year] or DDS::Duration_t::DURATION_INFINITE