posted on Thursday, October 07, 2010 - 08:31 pm
I have questions concerning the durability_service TRANSIENT when using OpenSplice v5.2. Is it not supposed to retain published values even after the publishing process dies? (as long as the DDS service continues to run, right?)I have a test case right now where I have a publisher publish a 10 instances of a keylisted topic having each their own unique ID. I then have a subscriber who uses a query condition and only cares about instances that have a keylisted ID of '6'. When the publisher dies, the subscriber continues to receive the last instance of of the the '6' ID. When I then kill the subscriber, and start its process again it receives no data. This is where I expect that there should be the last instance of this topic out there available for the Subscriber to read. Any thoughts?
posted on Thursday, October 07, 2010 - 09:19 pm
Turns out I found out what the problem was. By default the property durability_service.service_cleanup_delay is set to 0. Once I set it to the DDS defined constant for infinity, I had no problems getting the results from the TRANSIENT durability that I expected. Here's what I found in the OpenSplice API:
The DurabilityQosPolicy kind setting TRANSIENT_DURABILITY_QOS and PERSISTENT_DURABILITY_QOS determine that the DurabilityServiceQosPolicy applies for the Topic. It controls amongst others at which time the durability service is allowed to remove all information regarding a data-instance. Information on a data-instance is maintained until the following conditions are met: • the instance has been explicitly disposed of (instance_state = NOT_ALIVE_DISPOSED_INSTANCE_STATE), • and the system detects that there are no more “live” DataWriter objects writing the instance, that is, all DataWriter either unregister_instance the instance (call unregister_instance operation) or lose their liveliness, • and a time interval longer than service_cleanup_delay has elapsed since the moment the Data Distribution Service detected that the previous two conditions were met.
Even though you are right, setting the service_cleanup_delay to infinite might not be the 'right' solution for you. By doing this, the only way to 'remove' the data from your system is to reset all nodes. There is another way of preventing your instances to be removed when your process dies.
When a DataWriter is deleted explictly (by your application) or implicitly (because your appplication or node dies), all instances that are registered by that DataWriter are automatically unregistered by DDS. By default, the 'autodispose_unregistered_instances' boolean of the WriterDataLifecyleQosPolicy of a DataWriter is set to TRUE, causing instances to be disposed as well when unregistering.
So in your example, DDS will automatically dispose and unregister all instances when the DataWriter 'dies' causing all instances to reach their 'end-state' and to be removed.
Instead of setting the service_cleanup_delay to infinite I recommend to set the autodispose_unregistered_instances to FALSE. In this case, the state of instances will become NOT_ALIVE_NO_WRITERS, but they will not be disposed.
Would you be able to better explain the advantage of doing this rather than the service_cleanup_delay? It seems that in both ways the data remains out there and the only way to remove the data is to reset all nodes.
The advantage of this approach over the 'service_cleanup_delay' approach is that you can remove the data without resetting all nodes. When you want to remove a specific instance you can dispose it with a different DataWriter.
Let's consider autodispose_unregistered_instances is set to FALSE. In that case your instances will become NOT_ALIVE_NO_WRITERS when your writer 'dies'. If some other writer now 'disposes' one of these instances, it will implicitly register the instance (it becomes ALIVE) and dispose it (making it NOT_ALIVE_DISPOSED). When the DataWriter unregisters the instance, it will reach its 'end' state and will be removed.