We miss samples on a configuration topic. Reliability QoS is RELIABLE and durability is TRANSIENT LOCAL. The topic is published once on startup
and there are 1600 samples. However, I noticed that only 1024 is consistenly read. I have read some articles that mention this behavior:
http://community.rti.com/kb/why-does-my-dds-datareader-miss-first-few-samples, but the consistency of the magic number 1024 makes me wonder if
there is maybe a configuration setiing that needs to be changed. Both writer and reader have the QoS mentioned - if was verified with Analyzer.
Thank you
Nico.
Hi Nico,
What is your HISTORY Qos policy? Is it set to KEEP_LAST (this is the default). If so this maybe the problem.
Take a look at this posting as well: http://community.rti.com/kb/why-isnt-my-reliable-data-reader-receiving-all-data-samples
Gerardo
Hi Nico,
You can try to change the "max_samples_per_read " and "max_fragmented_samples" configurations to 1600 as the default values of them are 1024.
I am suggesting this approach because you always see that magic number 1024.
Thanks,
Kyoungho
Are you using read() or take() to access the data?
As Kyoungho pointed out, 1024 is the default value for the DataReaderQos.reader_resource_limits.max_samples_per_read (link to html docs for max_samples_per_read). This limit controls the number of samples that the application can receive from the middleware in a single call to read() or take(). If more data exists, the application will need to issue multiple read/take calls.
If you are using take(), the first call to take() will remove the first 1024 samples from the reader's local cache so that subsequent calls will return additional data samples (1025-1600, in your case). If you are using read(), then the call to read() will "keep" the samples in the reader's local cache. Subsequent calls to read() will return the same 1024 samples, unless you specify the DDS_NOT_READ_SAMPLE_STATE flag in the call to read().
As Kyoungho suggested, increasing the the max_samples_per_read can make sure you get all of the data in a single call to take() or read().
Hi Kyoungho and Sumeet,
As both of you recommended, increasing max_samples_per_read to 1600 resolves the issue. Thanks for the help
Nico.
Sumeet,
I am doing a read() on the data with SampleStateKind/NOT_READ_SAMPLE_STATE and still only get 1024 samples with multiple reads.
The other states used are
ResourceLimitsQosPolicy/LENGTH_UNLIMITED
ViewStateKind/ANY_VIEW_STATE
InstanceStateKind/ANY_INSTANCE_STATE
Anyway increasing the value of max_samples_per_read allows me to get all samples with one read
Thanks
Nico.
Here are some more information on the issue: I am using a StatusCondition to read new samples with StatusKind/DATA_AVAILABLE_STATUS enabled.
From the behaviour I saw, one can assume that the StatusCondition will only trigger once when all 1600 samples are in the reader cache and with
max_samples_per_read set to the default of 1024, only 1024 samples will be read(). Is it possible to trigger a StatusCondition for samples not read so that
it triggers multiple times or is a ReadCondition the only way to go ?
Thanks
Nico.
Hi Nico,
Your observation is correct - the StatusCondition (DATA_AVAILABLE_STATUS) triggers once the data arrives, but is cleared as soon as you call read()/take(). It will not be triggered again until new data arrives, even if you don't read everything that's available.
You have two options:
The logic goes something like this:
In this way, you're first checking if data is available before blocking in the WaitSet. This gets around the situation where there is unread data in the queue, but the WaitSet does not get woken up because the StatusCondition has not been re-triggered.
-sumeet