NEXEYA

Hello,

I noticed a different memory consumption on the reader size when using random instance keys or not.

Try that:

Hello,

I tried to use multi-channel datawriters with QoS protocol push_on_write set to FALSE (in order to have some kind of batching).

It seems to not work, and lead to erratic behavior in reception when I configure several channels for a datawriter.

When I switch push_on_write to TRUE, everything goes fine.

Is there some limitations on this configuration settings ?

Boris.

Hello,

I have two questions.

1 - What is the exact syntax of the <string pattern> used in MATCH filter expressions used in multichannel datawriters ? Though there is examples, it is not very clear in the documentations.

2 - Is it possible to use custom content filter for multichannel datawriters filtering configuration ?

Thank you.

Boris.

Hello,

My need in a few words is:

• strict reliability
• limited history (N samples)
• non blocking writer

My detailed need:

A late joining reader shall read only the last N written samples. Once these history samples read, the reader shall not lose any sample.

I don't mind if the writer consume as memory as it need to store samples that are not yet acked by the yet connected reader(s).

Hello,

I have a writer publishing a lot of topic instances (> 100 000), one sample per instance.

I want a late joining reader (or several) to get the last sample of each instances from the writer history.

I don't want the writer to block when writing samples.

I set the QoS for both datareader and datawriter:

KEEP_LAST_HISTORY_QOS
depth = 1

When the reader starts, all the samples are sent on the wire from the writer to the reader, leading to a huge peak in the flow of UDP packets.

Hello,

My scenario involve a datawriter and a datareader each one runs on its own host and exchanging topic instances through network.

I want the datareader side to be able to:
- Allocate resources (working processes for example) on creation of instances because the datawriter issues write keyed samples
- Free the resources on destruction of instances because the datawriter issues unregister or dispose (doesn't matter) of keyed samples, once they are created

Until now, no difficulty by reading status instances on the datareader side.

Hello,

We got a datareader receiving every 100 milliseconds (it's a mean value) batches of 100 samples each of the samples are 60 bytes in size. The datareader max_samples is 1000.

A thread takes samples into the datareader 100 by 100, using loaning function.

We observe that most of the time the "take" operation takes less than 200 microsecond but sometime (rarely) the "take" operation can takes as much as 3-6 milliseconds to return the loaned buffer.