Hi Ravi,
I think it is important to distinguish between the semantics of register/unregister_instance and dispose: The register/unregister_instance operations control resource usage both on the writer and on the reader side. When you register an instance on the writer side (either explicitly or implicitly by writing a sample with a key value that was not used before), you are allocating resources for storing this new instance both on the writer side and on the side of the connected readers. The resources used on the writer side are fully controlled by the writer itself, but the resources used on the side of the reader are sort of reference counted: a reader instance is only removed if BOTH the writer and the reader no longer refer to it. So when a writer unregisters an instance, it releases the resources it allocated to store the sample from the writer’s administration, and communicates to the connected readers that the writer no longer references the reader instance as well. However, the reader will not immediately release its instance resources upon reception of this writer-side unregister: it will only release the instance’s resources if all samples belonging to that instance have been taken out of the reader. Basically this means that if the writer never unregisters an instance OR the reader never takes away its samples, the instance resources on the reader side will never be reclaimed. Or to say it in another way: it doesn’t matter if the writer unregisters an instance: the reader will still hold on to it until it explicitly takes away all samples for that instance. The dispose semantics are not about resource management though: they are all about lifecycle management. Basically a dispose tells me that the instance is no longer alive (whatever that means for the data that the instance represents). So it can for example mean that the radar blib that was described by a writer instance has been shot down, and therefore the instance reached the end of its lifecycle. Since the writer is the entity observing the ‘real-life’ blib, it is the only one in the system that can make any claims on its lifecycle. Generally speaking you can say that once an instance is disposed by a writer, the writer can release its resources by unregistering the instance since it will no longer be sending updates for that instance. However, you cannot reverse this principle: an unregister by a datawriter does not by definition mean the end of the lifecycle for that instance. To go back into our radar blib example: the the blib can disappear from the radar because it drops below the radar’s observation horizon: that does not say anything about the lifecycle of this blib. The writer may decide to unregister the instance (because it does not expect to be writing any future updates to the instance), but is not making any assumptions about the lifecycle of this instance. On the reader side this is reflected in the instance’s end-state: in the first case it will become DISPOSED, in the latter case it will become NO_WRITERS. However, in both cases the instance data will remain available to the reading application until he explicitly takes (instead of reads) the instance, thereby reclaiming its resources. The ReaderDataLifcycleQosPolicy offers two fields that allow you to automatically reclaim instance resources that are either NO_WRITERS or DISPOSED without the need to explicitly take them. These are called autopurge_nowriter_samples_delay and autopurge_disposed_samples_delay. These policies will take away all samples for an instance that has been in the indicated state for more than the specified duration. If (and only if) the originating writer has already unregistered such an instance as well, then the reader will reclaim the instance resources whose samples have just been purged. I hope this gives some more background into the mechanisms and philosophies behind the unregister/dispose API’s. Basically my next question would be: what is the exact kind of problem that you are trying to solve by the desire to dispose an instance from the reader side? Regards, Erik Hendriks. > I think you are looking for the dispose method in the datawriter. > > On Fri, Apr 20, 2012 at 10:28 AM, Ravi Chandran > <[email protected] > > wrote: > >> Hi, >> >> I wanted to know that if we publish a message with >> auto_dispose_unregistered_instance of DataWriterQos set to false, is >> there a way to dispose this message when we have processed this >> message? As I see it now, whenever I run the subscriber I keep >> getting the message again and again, which seems correct logically, >> as the message will remain alive till we dispose it somehow.. >> >> Any hint towards this will be helpful. >> >> -- >> Thanks & Regards >> Ravi >> >> >> _______________________________________________ >> OpenSplice DDS Developer Mailing List [email protected] >> Subscribe / Unsubscribe >> http://dev.opensplice.org/mailman/listinfo/developer >> >> > > > -- > *Steve Mc Gregor* > email: [email protected] > movil: +51 992 705 909 > > > > _______________________________________________ > OpenSplice DDS Developer Mailing List > [email protected] > Subscribe / Unsubscribe > http://dev.opensplice.org/mailman/listinfo/developer > > With best regards, Erik *Erik Hendriks* Sr. Software Engineer Email: [email protected] Tel: +31-74-247-2575 Fax: +31-74-247-2571 Web: www.prismtech.com PrismTech is a global leader in standards-based, performance-critical middleware. Our products enable our OEM, Systems Integrator, and End User customers to build and optimize high-performance systems primarily for Mil/Aero, Communications, Industrial, and Financial Markets.
<<image001.jpg>>
_______________________________________________ OpenSplice DDS Developer Mailing List [email protected] Subscribe / Unsubscribe http://dev.opensplice.org/mailman/listinfo/developer
