Thanks Erik for this excellent explaination, this was very helpful for me in understanding the dispose vs unregister working. Okay, now coming back to my problem, I have some nodes with their own partitions, and at random point of time, I will be publishing some message to some or all of these partitions. Now, one of the scenario is that, suppose some of these nodes are down when i published the message to their partition ( I am using reliable and transient QOS ), how to make the messages reach the nodes that are down.
Its a typical case of getting historical data, I tried experimenting with just two nodes, and I found that when I was not using "autodispose instance = false", while unregistering the instance ( that was before reading your explaination ) and if I start DDS on the second node, I was not getting the message on subscriber end. But with autodispose = false, whenever I was restarting DDS, I was getting the same published messages again. and this was happening repeatedly. Now, the reason I am not disposing the message or setting the autopurge_nowriter_samples_delay and autopurge_disposed_samples_delay values which you mentioned is because I don't know if I dispose the message, whether it will dispose the messages for all the partitions for which Node1 published the message or not. What are the ways to clear out all the instances of a sample from Reader side once I receive the intended message? On Mon, Apr 23, 2012 at 6:11 PM, Erik Hendriks <[email protected]>wrote: > 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. > > > > _______________________________________________ > OpenSplice DDS Developer Mailing List > [email protected] > Subscribe / Unsubscribe > http://dev.opensplice.org/mailman/listinfo/developer > > -- Thanks & Regards Ravi
_______________________________________________ OpenSplice DDS Developer Mailing List [email protected] Subscribe / Unsubscribe http://dev.opensplice.org/mailman/listinfo/developer
