Home / , , / Why might Sample Data not arrive?

Why might Sample Data not arrive?

Why might Sample Data not arrive?

There are a couple of main reasons the sample data may not arrive and here are the causes, and solutions, to these problem

The Configuration is not Strict Reliable

Setting the Reliability Qos Policy to RELIABLE is not enough on its own to guarantee that a DataWriter delivers a sample to a matching DataReader. For this to always work the configuration must be set to be STRICT RELIABLE.

  1. Configure the DataWriter and DataReader ReliabilityQosPolicies to be RELIABLE. This ensures that the DataReader can ACK/NACK samples to show they are receiving everything and secondly that the DataWriter can repair NACKed samples if they have not arrived.
  2. Configure the DataWriter and DataReader HistoryQosPolicies to be KEEP_ALL. This means the DataWriter’s cache will keep all samples until ACKed and the DataReader’s cache will keep all samples until taken. Please note there is still a limit to the size of the cache queue which is determined by the Resource Limits QoS

see https://kbase.zettascale.tech/article/whats-relationship-reliability-history/ for more information on how these two options interact.

DataReader has not been discovered

If the DataReader you have is missing the initial samples from a DataWriter then it may be that the DataReader has not yet been discovered by the DataWriter. As there is no DataReader available to pick up the samples they have just been dropped until it is discovered. To address this problem you need to adjust the system.

You can either

  1. Configure the DataWriter so that it keeps samples available to later joiner DataReaders (or ones that have not been discovered yet). This is done using the Durability QoS options (see https://kbase.zettascale.tech/article/opensplice-durability-questions/#cmtoc_anchor_id_1) by setting this to anything other than VOLATILE. Note the number of samples available to late joiners depends on the History QoS kind. When this kind is set to KEEP_ALL, the size of the DataWriter’s queue is determined by the Resource Limits QoS. When history kind is set to KEEP_LAST, the size of the queue is determined by the history depth. (see https://kbase.zettascale.tech/article/whats-relationship-reliability-history/)
  2. Wait for the DataReaders to be discovered before publishing any samples. This may be as simple as starting the DataReaders first and pausing before starting the DataWriter but this is reliant on a clear understanding on timing. It is also possible to use the publication matched status with a listener/waitset but again this must be carefully used as you may have multiple DataReaders to wait for and you will need to know exactly how many you should have on the system. This is not so easy to maintain with system changes.

Here is a link to more detail on how discovery works in DDSI2. http://download.zettascale.online/www/docs/OpenSplice/v6/html/ospl/DeploymentGuide/ddsi2-networking-service.html#discovery-of-participants-endpoints.