OwnershipQosPolicy Class Reference
[OWNERSHIP]
Specifies whether it is allowed for multiple
com.rti.dds.publication.DataWriter (s) to write the same instance of the data and if so, how these modifications should be arbitrated.
More...
List of all members.
Detailed Description
Specifies whether it is allowed for multiple
com.rti.dds.publication.DataWriter (s) to write the same instance of the data and if so, how these modifications should be arbitrated.
- Entity:
- com.rti.dds.topic.Topic, com.rti.dds.subscription.DataReader, com.rti.dds.publication.DataWriter
- Status:
- StatusKind.OFFERED_INCOMPATIBLE_QOS_STATUS, StatusKind.REQUESTED_INCOMPATIBLE_QOS_STATUS
- Properties:
- RxO = YES
Changeable = UNTIL ENABLE
- See also:
- OWNERSHIP_STRENGTH
Along with the
OWNERSHIP_STRENGTH, this QoS policy specifies if
com.rti.dds.subscription.DataReader entities can receive updates to the same instance (identified by its key) from multiple
com.rti.dds.publication.DataWriter entities at the same time.
There are two kinds of ownership, selected by the setting of the kind:
SHARED and EXCLUSIVE.
OwnershipQosPolicyKind.SHARED_OWNERSHIP_QOS indicates that RTI Connext does not enforce unique ownership for each instance. In this case, multiple writers can update the same data type instance. The subscriber to the
com.rti.dds.topic.Topic will be able to access modifications from all
com.rti.dds.publication.DataWriter objects, subject to the settings of other QoS that may filter particular samples (e.g. the
TIME_BASED_FILTER or
HISTORY policy). In any case, there is no "filtering" of modifications made based on the identity of the
com.rti.dds.publication.DataWriter that causes the modification.
OwnershipQosPolicyKind.EXCLUSIVE_OWNERSHIP_QOS indicates that each instance of a data type can only be modified by one
com.rti.dds.publication.DataWriter. In other words, at any point in time, a single
com.rti.dds.publication.DataWriter owns each instance and is the only one whose modifications will be visible to the
com.rti.dds.subscription.DataReader objects. The owner is determined by selecting the
com.rti.dds.publication.DataWriter with the highest value of the
com.rti.dds.infrastructure.OwnershipStrengthQosPolicy.value that is currently alive, as defined by the
LIVELINESS policy, and has not violated its
DEADLINE contract with regards to the data instance.
Ownership can therefore change as a result of:
The behavior of the system is as if the determination was made independently by each
com.rti.dds.subscription.DataReader. Each
com.rti.dds.subscription.DataReader may detect the change of ownership at a different time. It is not a requirement that at a particular point in time all the
com.rti.dds.subscription.DataReader objects for that
com.rti.dds.topic.Topic have a consistent picture of who owns each instance.
It is also not a requirement that the com.rti.dds.publication.DataWriter objects are aware of whether they own a particular instance. There is no error or notification given to a com.rti.dds.publication.DataWriter that modifies an instance it does not currently own.
The requirements are chosen to (a) preserve the decoupling of publishers and subscriber, and (b) allow the policy to be implemented efficiently.
It is possible that multiple com.rti.dds.publication.DataWriter objects with the same strength modify the same instance. If this occurs RTI Connext will pick one of the com.rti.dds.publication.DataWriter objects as the owner. It is not specified how the owner is selected. However, the algorithm used to select the owner guarantees that all com.rti.dds.subscription.DataReader objects will make the same choice of the particular com.rti.dds.publication.DataWriter that is the owner. It also guarantees that the owner remains the same until there is a change in strength, liveliness, the owner misses a deadline on the instance, or a new com.rti.dds.publication.DataWriter with higher same strength, or a new com.rti.dds.publication.DataWriter with same strength that should be deemed the owner according to the policy of the Service, modifies the instance.
Exclusive ownership is on an instance-by-instance basis. That is, a subscriber can receive values written by a lower strength com.rti.dds.publication.DataWriter as long as they affect instances whose values have not been set by the higher-strength com.rti.dds.publication.DataWriter.
The value of the
com.rti.dds.infrastructure.OwnershipQosPolicyKind offered must exactly match the one requested or else they are considered incompatible.
The need for registering/unregistering instances stems from two use cases:
- Ownership resolution on redundant systems
- Detection of loss in topological connectivity
These two use cases also illustrate the semantic differences between the com.rti.dds.topic.example.FooDataWriter.unregister_instance and com.rti.dds.topic.example.FooDataWriter.dispose.
It is expected that users may use DDS to set up redundant systems where multiple
com.rti.dds.publication.DataWriter entities are "capable" of writing the same instance. In this situation, the
com.rti.dds.publication.DataWriter entities are configured such that:
- Either both are writing the instance "constantly"
- Or else they use some mechanism to classify each other as "primary" and "secondary", such that the primary is the only one writing, and the secondary monitors the primary and only writes when it detects that the primary "writer" is no longer writing.
Both cases above use the
OwnershipQosPolicyKind.EXCLUSIVE_OWNERSHIP_QOS and arbitrate themselves by means of the
com.rti.dds.infrastructure.OwnershipStrengthQosPolicy. Regardless of the scheme, the desired behavior from the
com.rti.dds.subscription.DataReader point of view is that
com.rti.dds.subscription.DataReader normally receives data from the primary unless the "primary" writer stops writing, in which case the
com.rti.dds.subscription.DataReader starts to receive data from the secondary
com.rti.dds.publication.DataWriter.
This approach requires some mechanism to detect that a com.rti.dds.publication.DataWriter (the primary) is no longer "writing" the data as it should. There are several reasons why this may happen and all must be detected (but not necessarily distinguished):
- [crash] The writing process is no longer running (e.g. the whole application has crashed)
- [connectivity loss] Connectivity to the writing application has been lost (e.g. network disconnection)
- [application fault] The application logic that was writing the data is faulty and has stopped calling com.rti.dds.topic.example.FooDataWriter.write.
Arbitrating from a
com.rti.dds.publication.DataWriter to one of a higher strength is simple and the decision can be taken autonomously by the
com.rti.dds.subscription.DataReader. Switching ownership from a higher strength
com.rti.dds.publication.DataWriter to one of a lower strength
com.rti.dds.publication.DataWriter requires that the
com.rti.dds.subscription.DataReader can make a determination that the stronger
com.rti.dds.publication.DataWriter is "no longer writing the instance".
This determination is reasonably simple when the data is being written periodically at some rate. The
com.rti.dds.publication.DataWriter simply states its offered
com.rti.dds.infrastructure.DeadlineQosPolicy (maximum interval between updates) and the
com.rti.dds.subscription.DataReader automatically monitors that the
com.rti.dds.publication.DataWriter indeed updates the instance at least once per
com.rti.dds.infrastructure.DeadlineQosPolicy.period. If the deadline is missed, the
com.rti.dds.subscription.DataReader considers the
com.rti.dds.publication.DataWriter "not alive" and automatically gives ownership to the next highest-strength
com.rti.dds.publication.DataWriter that
is alive.
The case where the
com.rti.dds.publication.DataWriter is not writing data periodically is also a very important use-case. Since the instance is not being updated at any fixed period, the "deadline" mechanism cannot be used to determine ownership. The liveliness solves this situation. Ownership is maintained while the
com.rti.dds.publication.DataWriter is "alive" and for the
com.rti.dds.publication.DataWriter to be alive it must fulfill its
com.rti.dds.infrastructure.LivelinessQosPolicy contract. The different means to renew liveliness (automatic, manual) combined by the implied renewal each time data is written handle the three conditions above [crash], [connectivity loss], and [application fault]. Note that to handle [application fault], LIVELINESS must be
LivelinessQosPolicyKind.MANUAL_BY_TOPIC_LIVELINESS_QOS. The
com.rti.dds.publication.DataWriter can retain ownership by periodically writing data or else calling assert_liveliness if it has no data to write. Alternatively if only protection against [crash] or [connectivity loss] is desired, it is sufficient that some task on the
com.rti.dds.publication.DataWriter process periodically writes data or calls
com.rti.dds.domain.DomainParticipant.assert_liveliness. However, this scenario requires that the
com.rti.dds.subscription.DataReader knows what instances are being "written" by the
com.rti.dds.publication.DataWriter. That is the only way that the
com.rti.dds.subscription.DataReader deduces the ownership of specific instances from the fact that the
com.rti.dds.publication.DataWriter is still "alive". Hence the need for the
com.rti.dds.publication.DataWriter to "register" and "unregister" instances. Note that while "registration" can be done lazily the first time the
com.rti.dds.publication.DataWriter writes the instance, "unregistration," in general, cannot. Similar reasoning will lead to the fact that unregistration will also require a message to be sent to the
com.rti.dds.subscription.DataReader.
There are applications that are designed in such a way that their correct operation requires some minimal topological connectivity, that is, the writer needs to have a minimum number of readers or alternatively the reader must have a minimum number of writers.
A common scenario is that the application does not start doing its logic until it knows that some specific writers have the minimum configured readers (e.g the alarm monitor is up).
A more common scenario is that the application logic will wait until some writers appear that can provide some needed source of information (e.g. the raw sensor data that must be processed).
Furthermore, once the application is running it is a requirement that this minimal connectivity (from the source of the data) is monitored and the application informed if it is ever lost. For the case where data is being written periodically, the com.rti.dds.infrastructure.DeadlineQosPolicy and the on_deadline_missed listener provides the notification. The case where data is not periodically updated requires the use of the com.rti.dds.infrastructure.LivelinessQosPolicy in combination with register_instance/unregister_instance to detect whether the "connectivity" has been lost, and the notification is provided by means of InstanceStateKind.NOT_ALIVE_NO_WRITERS_INSTANCE_STATE.
In terms of the required mechanisms, the scenario is very similar to the case of maintaining ownership. In both cases, the reader needs to know whether a writer is still "managing the current value of an instance" even though it is not continually writing it and this knowledge requires the writer to keep its liveliness plus some means to know which instances the writer is currently "managing" (i.e. the registered instances).
com.rti.dds.topic.example.FooDataWriter.dispose is semantically different from com.rti.dds.topic.example.FooDataWriter.unregister_instance. com.rti.dds.topic.example.FooDataWriter.dispose indicates that the data instance no longer exists (e.g. a track that has disappeared, a simulation entity that has been destroyed, a record entry that has been deleted, etc.) whereas com.rti.dds.topic.example.FooDataWriter.unregister_instance indicates that the writer is no longer taking responsibility for updating the value of the instance.
Deleting a com.rti.dds.publication.DataWriter is equivalent to unregistering all the instances it was writing, but is not the same as "disposing" all the instances.
For a com.rti.dds.topic.Topic with OwnershipQosPolicyKind.EXCLUSIVE_OWNERSHIP_QOS, if the current owner of an instance disposes it, the readers accessing the instance will see the instance_state as being "DISPOSED" and not see the values being written by the weaker writer (even after the stronger one has disposed the instance). This is because the com.rti.dds.publication.DataWriter that owns the instance is saying that the instance no longer exists (e.g. the master of the database is saying that a record has been deleted) and thus the readers should see it as such.
For a com.rti.dds.topic.Topic with OwnershipQosPolicyKind.EXCLUSIVE_OWNERSHIP_QOS, if the current owner of an instance unregisters it, then it will relinquish ownership of the instance and thus the readers may see the value updated by another writer (which will then become the owner). This is because the owner said that it no longer will be providing values for the instance and thus another writer can take ownership and provide those values.
Member Data Documentation