Quick question:
I have a topic, I intend to use it without a key, however it seems to work the same with keys. The topic has a QoS of exclusive ownership. I have two or more publishers with different ownership strengths.
When I run the subscriber and the publishers everything works as expected with one minor issue (which I cannot determine via any documents if this is actually an issue or working as designed). The issue is that the lower strength publisher is received until the higher strength publisher writes a message (both have instant liveliness as soon as they run because I create the publishers right away). I can tell because I get a callback in the subscriber of a liveliness change and can print out the number of publishers. The higher strength publisher has a longer delay before it begins to write, so the lower strength publisher is the first to write on the topic. Of course once they both write, then the lower strength (and more often) publisher is not listened to (until liveliness is lost).
It should be noted I am using automatic liveliness and that I have tried this with keys (in which case I performed a register_instance() using the key at the beginning of the publishers well before I wrote any messages). It should also be noted that I am using a listener for receiption of messages rather than a polling read() or take(), however that should not matter.
Is this expected behavior, or have I messed something up?
Thanks in advance.
Hey,
I believe that exclusive ownership affects per instance and only for deciding between different writers that are writing that instance.
In fact, https://community.rti.com/static/documentation/connext-dds/5.2.3/doc/manuals/connext_dds/RTI_ConnextDDS_CoreLibraries_QoS_Reference_Guide.pdf seems to verify what I've just said.
So it seems this is the desired behavior :)
Have fun,
Roy.
I agree it "seems" to be the behavoir, I guess I just would like to see or have something that specifically indicates this.
One could expect, based on the documentation that I have seen, that the highest strength alive publisher regardless of whether it has wrote anything yet would "own" the instance if one of the following were true:
1. The topic in question with exclusive ownership is keyless
2. The topic in question with exclusive ownership is keyed and the highest strength publisher has performed a register_instance() with the proper key
There seems to be an extra requirement that a publish (write) has to happen in order to "grab" the ownership, but none of the documentation says that. The documention and countless discussions or references online leave it up to interpretation that the way I described above was the way it worked, when it does not seem to work that way.
Put simply, it seems it is not enough to be ready to publish on something to take exclusive ownership of it, you have to actually publish a message to do it. When writing a manager style application that uses infrequent commands with failover capability, this sort of thing makes a difference.
Thanks.
Hey mwmalopo,
First, I agree it is not COMPLETELY clear from the documentation and there's a certain amount of interpretation needed but I would like to point out a few reasons why I think it makes sense:
1. When two (or more) applications are writing the same data (to achieve a maximum level of fault tolerance), it makes sense that if a specific writer didn't write a sample for an instance and another did, this indicates a problem with the writer that did not write a sample.
2. When two (or more) applications are writing to a topic using user actions (so that each application is possibly handled by a different user but we only want one user to actually modify a topic) you can easily claim ownership over the topic+instance combination by sending some takeover sample when starting up the application (and use liveliness to detect if the writer stops being responsive).
3. If your SLA includes some requirement on the update rate of a certain instance, you can use the deadline qos to determine when a writer isn't performing as well as it is required to.
I'm not sure what your use case is (why are different applications writing different commands? what kind of failover capability do you wish to create?) but maybe http://community.rti.com/docs/html/api_dotnet/structDDS_1_1OwnershipQosPolicy.html can help you out, it seems to be a good read.
Good luck,
Roy.