Detecting dead writers/publishers (Java)

Hello Mike,

Yuu can detect the presence (apperance and dissapearance) of DataWriters and any other DDS entity by subscribing and reading the DDS Builtin Topics. This would notify via callbacks each time a new DataWriter joins or leaves the system so you do not have to "poll" at any period. These two articles describe how to do it:

https://community.rti.com/howto/detect-presence-domainparticipants-datawriters-and-datareaders-dds-domain

https://community.rti.com/kb/how-can-i-detect-new-datawriters-and-datareaders-joining-domain

But in a data-centric system often the important thing is not whether a specific DataWriter is present but rather whether there is some DataWriter that is writing a specific data-object instance. In other words, assume you have a system where you are publishing Temperature data on a "TemperatureSensor" topic. The data-type associated with this Topic may have the temperature value, other info such as the unit, and also (significatly) the ID that uniquely dentifies that sensor (whoch would be marked as key). For example

struct TemperatureSensorType {
   long sensor_id; //@Key
   float temperature_value;
   string<16> temperature_units;  
};  

Thes temperatures could be published peridically, or perhaops only when there is a significant change.

Now you could have a system where each Temperature Sensor is written by a separate DataWriter. So if you wanted to know that a particular sensor is no longer being published then you could just monitor the "presence" of that DataWriter and thus see that has gone away.

However the above approach would be architecturally brittle and not "data-centric" in that some "sensor monitoring" applications know that each Sensor uses a separate data-writer. What if you decided at a separate point to create a single application that monitors multiple sensors and uses the same writer to publish data on both sensors. What of you had some tool to "replay old sensor data" or to inject data based on a UI for testing pusposes... All these situatuons would break the "one-sensor one DataWriter" rule in which the logic of monitoring the DataWriter was based.

A "data-centric" (and less brittle) way to do this is to monitor that each sensor is being published by some (at least one) DataWriter without having to monitor and track each DataWriters directly. This is precisely what the LIVELINESS Qos Policy provides. On the DataReader can set the lease_duration of the LIVELINESS Qos Policy lease_duration to the period at which you want the middleware to internally monitor that each "data instance" is still being published by someone. On the DataWriter you must set the LIVELINESS Qos Policy lease_durationto the value at which the DataWriter will inform readers of its active presence.  Note the configured DataWriter lease_duration must be smaller or equal to the  DataReader's or otherwuse DDS will notify you of an incompatible Qos.

With this setting you will be notified of instances that have no longer a DataWriter writing them via a DataReader on_data_available callback with Samples that have a SampleInfo with the instance_state set to  NOT_ALIVE_NO_WRITERS. 

Note that in the default Qos settings the lease_duration is set to INFINITE so this mechanism is not active.

Note also that you must have declared some key attributes in your data type. As indicated above using the //@Key annotation.

Take also a look at the use of Liveliness Policy Kind. A setting of DDS_AUTOMATIC_LIVELINESS_QOS is allows the detection to use automatic heartbeating mechanisms implememted by the middleware infrastructure. So there is nothing else to do to ensure the liveliness "heartbeats" are sent as required by the DataWriter's lease_duration. However if you want stronger control of this so that liveliness is only refreshed when the application saya so, then the DDS_MANUAL_BY_PARTICIPANT_LIVELINESS_QOS or the DDS_MANUAL_BY_TOPIC_LIVELINESS_QOS would be the ones to use.

Regards,

Gerardo