In version 0.11.2 subscriber/reader no longer receives data if started 6 seconds after the publisher/writer

[andrei-ng]

Since the latest crates.io release, version 0.11.2 , I noticed that the subscribers I am using no longer receive data if started after the publisher/writer entity. By the way, could you push the 0.11.2 tag to the GitHub repo as well, I see it is missing.

I am using BestEffort QoS, but I have tried reliable QoS as well with the same effect.

I checked the differences between versions 0.11.1 and 0.11.2 and the one that stood out was this

Prior to 0.11.2 the clean cache period was set to 2 minutes

let cache_cleaning_period = Duration::from_secs(2 * 60);

now in it was set to 6 seconds

let cache_cleaning_period = Duration::from_secs(6);

I did some silly tests where I changed the period value and indeed as long the subscriber is (re)started within this hardcoded value, communication between Subscriber and Publisher is always achieved. Stopping the subscriber after that period and restarting it leads to no communication.

Is this expected behavior? Am I doing something wrong or have the wrong expectations? It was my assumption that with DDS, it is not important when the subscriber is started, discovery will ensure that readers and writers will be matched and commincation will be achieved if the QoS contracts are met.

If you need more data I can try to build a minimal example and push it somewhere.

[jhelovuo]

Thank you for the report.

Subscribers should receive published data regardless of the starting order. Publisher needs to either (1) publish samples after connecting to a Subscriber, or (2) have QoS policies History and Durability specified so that some past samples are retained in the Publisher. If neither (1) or (2) holds, then it is normal for data to get lost.

Did you test that you actually get different results with versions 0.11.2 and 0.11.1 ?

Yes, it would good if you could make a minimal example code to reproduce the problem you are seeing. If modifying and publishing your existing code is problematic, then maybe you could use code derived from RustDDS examples as a starting point.

[andrei-ng]

Hi @jhelovuo ,
Thank you for your reply.

Yes, I tried both 0.11.2 and 0.11.1

With 0.11.2 if I start the subscriber after the publisher (about 10 seconds after) I can not get data.
Once I restart the publisher, communication is achieved.

I will try to make a stripped down example by the end of this week.

[andrei-ng]

Hi @jhelovuo

I created an example with the same setup as the code where I encountered the issue, using latest version of RustDDS. I published it in one of my repos and can be found here: https://github.com/andrei-ng/u-blox.rs/tree/add-dds-examples/examples/dds

Can be built by running cargo build -p dds --release from the examples folder. It will create a dummy publisher and a subscriber.

The publisher can be started like so

LOG_LEVEL=info ./target/release/dummy-publisher -t test

And the subscriber

LOG_LEVEL=info ./target/release/subscriber -t test

By default the subscriber subscribes to the topic ubx-nav-pvt of NavPvt type (the publisher publishes 2 more topics, but the behavior is the same on any of these topics as they are created with the same setup)

If the publisher is started first and then after about 10 seconds the subscriber is started, no communication is achieved. Restarting the publisher makes the subscriber get data.