Re: [opendds-main] Problem with QoS Policies

[Jeff S. <sch...@oc...>]

Hi Alex,

A few points

1. In the subscriber, it is not enough to check the status of take_next
sample().  You should also check info.valid_data

2. In the publisher, if you want it to behave reliably, change the history
kind to KEEP_ALL_HISTORY_QOS, and use resource limits to control the number
of samples in history.  Then check for a timeout status from the write()
call.  See the Reliability example.

3. Use TCP transport, if you are not.  It is the most trusted transport of
OpenDDS

If this does not fix your problem, I'd suggest starting with the
reliability example, and working your way back to your example to see the
difference.

jeff

On Thu, Nov 27, 2014 at 3:02 AM, Alex Douckas <ale...@gm...> wrote:

> Hello,
>
> I have created a publisher application and a subscriber one ( both in
> C++ ) with the following QoS policies on both Topic and DataWriter (
> and DataReader respectively ) :
>
> DDS::TopicQos default_topic_qos;
> participant->get_default_topic_qos(default_topic_qos);
> default_topic_qos.history.kind = DDS::KEEP_LAST_HISTORY_QOS;
> default_topic_qos.history.depth = 140000;
> default_topic_qos.reliability.kind = DDS::RELIABLE_RELIABILITY_QOS;
>
> DDS::DataWriterQos dw_default_qos;
> pub->get_default_datawriter_qos (dw_default_qos);
> dw_default_qos.history.kind = DDS::KEEP_LAST_HISTORY_QOS;
> dw_default_qos.history.depth = 140000;
> dw_default_qos.reliability.kind = DDS::RELIABLE_RELIABILITY_QOS;
>
> Now, the publisher is sending about 3000 data samples, each one every
> 100 miliseconds. So to test the history and reliability policies, I
> set a delay on the subscriber ( with usleep) of 500 miliseconds on the
> "on_data_available" class like this :
>
>       DDS::SampleInfo si ;
>       DDS::ReturnCode_t status = measurement_dr->take_next_sample(data,
> si) ;
>
>       if (status == DDS::RETCODE_OK) {
>          //omitted Code that manipulates the data sample
>
>              usleep (500000);
>
>        } else if (status == DDS::RETCODE_NO_DATA) {
>         cerr << "INFO: reading complete after " << count << " samples." <<
> endl;
>         break;
>       }
>
> The problem is that after about 1000 received samples, the subscriber
> somehow stops receiving the rest samples. Since the depth of History
> is bigger than the samples, the subscriber should receive everything.
> The same thing happens even if I use KEEP_ALL_HISTORY instead of
> KEEP_LAST. Do you have any idea about this issue ?  Am I using the
> policies wrong ?
>
> Thanks,
> Alex
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> opendds-main mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opendds-main
>