This article contains some user submitted OpenSplice general configuration questions that may prove useful to others.
See the OpenSplice documentation for more information.
How does the Deadline QoS Policy work?
The Deadline QoS Policy can be set on DataReaders, DataWriters or Topics. For a data reader it defines the time period within which a new sample is expected. For a writer it defines the time period within which a new sample should be written. The Deadline Qos has no functionality when it is set on a topic. It is used as a default value for readers and writers, which can use it by means of copy_from_topic_qos. They can then use set_qos to set the property. This allows you to store the QoS in one place that is used by all the readers and writers. Individual readers and writers can overwrite this if required.
The Deadline QoS does not affect the data itself, any data sent or received late will still be handled. In order to detect that the deadline has passed, you can either use a listener or a wait set. Which you use depends on the needs of your application (a listener will be invoked asynchronously, for example). If you use a listener, you could use the listener event as a signal that the data did not arrive on time and your application can deal with this appropriately.
Can I create multiple Topics with the same name but different QoS properties?
No. The OMG DDS specification cannot support this.
How can I receive data in the order it was sent?
In order to control the send/receive order the order should be controlled by the source timestamp. This can be controlled by setting the DestinationOrderQosPolicy to BY_SOURCE_TIMESTAMP. The method by which this is accomplished varies between language API’s. Refer to your specific language guide here for more information.
I have two writers with different OwnershipStrength values. Can you tell me how I can set up a reader to read the strongest being sent?
The OwnershipStrengthQoSPolicy is set on DataWriters to specify the value of the ownership strength of an instance. In order for the DataReaders to read the instance which is sent by the DataWriter with the strongest OwnershipStrengthQoSPolicy you need to set the OwnershipQoSPolicy on the topic to EXCLUSIVE_OWNERSHIP_QOS.
The OwnershipQoSPolicy determines if the DataWriter owns the instance. It can only be set on a topic. It has two kind attributes that can be set:
- SHARED_OWNERSHIP_QOS (which is the default). This allows the same instance to be written by multiple data writers. All the updates are made available to the Data Readers.
- EXCLUSIVE_OWNERSHIP_QOS – The instance will only be accepted from one data writer. The DataWriter with the highest OwnershipStrengthQoSPolicy value which is alive (LivelinessQoSPolicy) and which has not violated the DeadlineQoSPolicy will be the owner of the instance.
When the OwnershipQoSPolicy is set to EXCLUSIVE_OWNERSHIP_QOS and the writer is specifying its strength with OwnershipStrengthQoSPolicy then the middleware determines the strongest writer at all times when new samples are received by the reader.
What is the TopicQos used for?
The TopicQos does not impose anything on individual readers/writers. Each reader/writer can make its own QoS decisions, regardless of the topic settings.
The TopicQos provides a hint to readers and writers as to what QoS policies to use. If a reader or writer does not know what values will work in a given system it can copy the settings from the topic.
There are special helper-operations on the Publisher and Subscriber (copy_from_topic_qos) for this, and there are also convenience macro’s that do the same trick.
In a typical system, the system architect defines the overall information model. That model defines all topics including their TopicQoS settings. Typical applications follow these policy guidelines set by the system architect.
In exceptional cases it may be necessary that individual applications need to deviate from the policies as set by the system architects. For those cases individual readers/writers may override the topic settings. (Normally this should be discussed with the system architect). For those readers/writers the standard compatibility rules apply with the rest of the system.
Please not that the compatibility rules are only evaluated between Readers and Writers. The TopicQos is only considered a hint by the system so no individual Reader/Writer will be considered incompatible with the Topic. However, since the rest of the system probably follows the TopicQos, you may end up being in conflict with all other Readers/Writers in the system.