To reproduce the problem, set the following QoS
dds::TopicQos qos;
qos.set_reliable();
qos.set_transient();
qos.set_keep_all();
qos.set_resource_limits(10000, 10000, 10000);
On the DR on_data_available functor, use code similar to this:
void handle_mytype(dds::DataReader<My::MyType> reader) {
My::MyTypeSeq samples;
DDS::SampleInfoSeq infos;
reader.read(samples, infos);
for (unsigned int i = 0; i < samples.length(); ++i) {
std::string id(samples[i].id);
int value = atoi(id.c_str());
if (value % 1000 == 0) {
std::cout << "id =>> " << samples[i].id << std::endl;
std::cout << "count = " << count << std::endl;
}
count++;
}
reader.return_loan(samples, infos);
}
The DW looks like this:
dds::Runtime runtime(ss.str());
dds::TopicQos qos;
qos.set_reliable();
qos.set_transient();
qos.set_keep_all();
qos.set_resource_limits(10000, 10000, 10000);
dds::DataWriterQos dwQoS(qos);
dds::Topic<My::MyType> topic("topic", qos);
dds::DataWriter < My::MyType > *writer;
writer = new dds::DataWriter<My::MyType>(topic, dwQoS);
for (int i = 0; i < 100000; i++) {
My::MyType sample;
std::string s;
std::stringstream out;
out << i;
std::string id = out.str();
sample.id = DDS::string_dup(id.c_str());
writer->write(sample);
if (i % 100 == 0)
std::cout << "published sample #" << i << std::endl;
usleep(100);
}
The expected output would be for the shared memory to get cleaned up after it's
read on the DR and/or the DW's shared pointer gets cleaned up after writing a
sample. Something like an unregister_instance() call should be made in the DDS
API?
Instead, I see the shared memory keep growing until it reaches the limits set
in the QoS, then it pauses, and then another sample is set at an extremely slow
rate. I would expect the memory to never reach those limits (since my test
machine isn't heavily loaded) and keep getting freed as it's read.
I tested this with SIMD 0.9, OpenSplice Community Edition 5.3, on both Ubuntu
11.04 and RHEL 5.4.
Please see: http://forums.opensplice.org/index.php?/topic/1219-reliable-qos/
for additional details.
Original issue reported on code.google.com by stef.dum...@gmail.com on 30 Jan 2011 at 4:32
Original issue reported on code.google.com by
stef.dum...@gmail.com
on 30 Jan 2011 at 4:32