I would need to test or check the implementation to be sure but from the conceptual definition I think the on_requested_deadline_missed should be called.
The fact that the Lifespan expires on the DataReader side should cause the sample to be "removed" from the DataReader cache even if the application never did a take (or a read) on the sample. But this is about keeping a sample around, which is orthogonal to the DEADLINE (i.e. the requirement to update each instance at a certain minimum period).
Because the "deadline" of the DataReader is enforced by instance, its tracking is maintained also per instance and not tied to a particular sample. When a sample arrives is refreshes the "last update time" for the whole instance (independent of the writer that sent the sample). The "last update time" is kept with the instance "state" so even if all samples for the instance are removed (e.g. via a take, or a Lifespan expiration) the knowlegde of when the instance was last updated is retained.
The DataReader will check at the DEADLINE period if each instance was updated and call on_requested_deadline_missed() for each instance where this did not happen, so I think the fact that the Lifespan may have expired should have no impact if this.
I guess I have a more basic problem: I tried increasing the lifespan to 45 sec thus making it greater than the deadline (40 sec). The deadline-missed callback is not invoked in this case, either.
I am attaching the QoS display from the Admin Console.
Would you have a hint as to what could cause the absence of the deadline-missed event?
Let's make sure the basic assumptions are correct:
(1) Both DataWriter and DataReader define a deadline (it seems so from your Qos dump even if in the images one of the is cut.
(2) The Topic does define a key field(s). This should be observable in admin console if you look at the associated data type.
(3) The DataWriter has written that instance previously. If the instance is never written the DataReader does not know about it and it never checks the deadlines
(4) The instance has not been unregistered or deleted by the DataWriter. I do not recall if only "ALIVE" instances trigger the on_requested_deadline_missed calback
(5) There is no other DataWriter writing the instance. Deadline is per instance, not per writer-instance.
If all the above are true I think the next step would be to try a simple reproducer where you create a "hello world" straingt from rtiddsgen setting the Qos that you are using and try to see if the problem also occurs there. If you can reproduce it and post that we should be able to track it down efficiently.
After further analysis it turned out that we had a writer side mechanism running where the last update of each topic instance was being periodically resent every 30 sec. This kept the deadline from firing.
Hi,
I would need to test or check the implementation to be sure but from the conceptual definition I think the on_requested_deadline_missed should be called.
The fact that the Lifespan expires on the DataReader side should cause the sample to be "removed" from the DataReader cache even if the application never did a take (or a read) on the sample. But this is about keeping a sample around, which is orthogonal to the DEADLINE (i.e. the requirement to update each instance at a certain minimum period).
Because the "deadline" of the DataReader is enforced by instance, its tracking is maintained also per instance and not tied to a particular sample. When a sample arrives is refreshes the "last update time" for the whole instance (independent of the writer that sent the sample). The "last update time" is kept with the instance "state" so even if all samples for the instance are removed (e.g. via a take, or a Lifespan expiration) the knowlegde of when the instance was last updated is retained.
The DataReader will check at the DEADLINE period if each instance was updated and call on_requested_deadline_missed() for each instance where this did not happen, so I think the fact that the Lifespan may have expired should have no impact if this.
Are you observing something different from this?
Gerardo
Hi Gerardo,
Yes I am observing that I am not getting the on_requested_deadline_missed in this case.
Let me double check.
Here is our Writer side QoS. "wQos" is of type DataWriterQos:
wQos.publish_mode.kind = PublishModeQosPolicyKind.ASYNCHRONOUS_PUBLISH_MODE_QOS;
wQos.publish_mode.flow_controller_name = "ActacorFlowController";
wQos.deadline.period.nanosec = 0;
wQos.deadline.period.sec = 40;
wQos.durability.kind = DurabilityQosPolicyKind.TRANSIENT_DURABILITY_QOS;
wQos.history.kind = HistoryQosPolicyKind.KEEP_LAST_HISTORY_QOS;
wQos.history.depth = 3;
wQos.lifespan.duration.nanosec = 0;
wQos.lifespan.duration.sec = 30;
wQos.reliability.kind = ReliabilityQosPolicyKind.RELIABLE_RELIABILITY_QOS;
wQos.resource_limits.max_instances = 21000;
wQos.resource_limits.initial_instances = 2100;
Here is our Reader side QoS. "rQos" is of type DataReaderQos:
rQos.deadline.period.nanosec = 0;
rQos.deadline.period.sec = 40;
rQos.durability.kind = DurabilityQosPolicyKind.TRANSIENT_DURABILITY_QOS;
rQos.history.kind = HistoryQosPolicyKind.KEEP_LAST_HISTORY_QOS;
rQos.history.depth = 3;
rQos.reliability.kind = ReliabilityQosPolicyKind.RELIABLE_RELIABILITY_QOS;
rQos.resource_limits.max_instances = ResourceLimitsQosPolicy.LENGTH_UNLIMITED;
I guess I have a more basic problem: I tried increasing the lifespan to 45 sec thus making it greater than the deadline (40 sec). The deadline-missed callback is not invoked in this case, either.
I am attaching the QoS display from the Admin Console.
Would you have a hint as to what could cause the absence of the deadline-missed event?
Hello,
Nothing in the Qos stands out as problematic.
Let's make sure the basic assumptions are correct:
(1) Both DataWriter and DataReader define a deadline (it seems so from your Qos dump even if in the images one of the is cut.
(2) The Topic does define a key field(s). This should be observable in admin console if you look at the associated data type.
(3) The DataWriter has written that instance previously. If the instance is never written the DataReader does not know about it and it never checks the deadlines
(4) The instance has not been unregistered or deleted by the DataWriter. I do not recall if only "ALIVE" instances trigger the on_requested_deadline_missed calback
(5) There is no other DataWriter writing the instance. Deadline is per instance, not per writer-instance.
If all the above are true I think the next step would be to try a simple reproducer where you create a "hello world" straingt from rtiddsgen setting the Qos that you are using and try to see if the problem also occurs there. If you can reproduce it and post that we should be able to track it down efficiently.
Gerardo
Hello Gerardo,
After further analysis it turned out that we had a writer side mechanism running where the last update of each topic instance was being periodically resent every 30 sec. This kept the deadline from firing.
Thanks for your helpful input,
Oliver