* Deadlines are applicable to instances and, on the reader side, can be applied on data coming from different Writers. * Liveliness is applicable to Writers, and will impact all instances belonging to a writer whose lease_duration expired.
So it is possible to use both QosPolicies at the same time with different timing characteristics. Certain events may violate both constraints: the timing values in the QosPolicies will then decide which mechanism is triggered first.
188.8.131.52.1.1 Case where the data is periodically updated
This determination is reasonably simple when the data is being written eriodically at some rate. The DataWriter simply states its offered DEADLINE (maximum interval between updates) and the DataReader automatically monitors that the DataWriter indeed updates the instance at least once per deadline period. If the deadline is missed, the DataReader considers the DataWriter “not alive” and automatically gives ownership to the next highest-strength DataWriter that is alive.
184.108.40.206.1.2 Case where data is not periodically updated
The case where the DataWriter is not writing data periodically is also a very important use-case. Since the instance is not being updated at any fixed period, the “deadline” mechanism cannot be used to determine ownership. The liveliness solves this situation. Ownership is maintained while the DataWriter is “alive” and for the DataWriter to be alive it must fulfill its “LIVELINESS” QoS contract.
................................... This suggests to me that, for the purposes of ownership, liveliness is ignored when a deadline of non-infinite is declared?
No, liveliness is not ignored when deadlines are set to a non-infinite value: in such cases both mechanisms will be used at the same time. The QoS whose contract is violoated first will be the one that is triggered first.
Consider for example a situation in which the deadline is set to 6 seconds (I expect each instance to be updated every 6 seconds), but the liveliness is set to 100ms (I want to know if my Writer looses connection or gets stuck in an eternal loop). In this case the liveliness Qos may trigger before actually one of my deadlines has expired.
Another example could be a Topic that has shared ownership, and a Reader that receives updates from multiple writers for the same instances. In that case the Reader deadlines can all be met, while one of the Writers can become disconnected. Also in such a case may the LivelinessQos help you to find out that one of your Writers is having a problem.
Regards, Erik Hendriks.
Anonymous posted on Wednesday, April 14, 2010 - 10:13 am
I am using OwnershipQos policy of DDS. But problem is the datareader takes data from both datawriters even though OwnershipStrength value is different for both datawriter. As i understand in such case reader should receive data from higher strength data writer.
Please suggest which other QOS has to be modified to achieve proper result?