I have two applications using RTI 5.1.0 x64Win64jdk, both using the same topic and type. One application has a publisher, and the other a subscriber. Both have a QoS durability of TRANSIENT_LOCAL_DURABILITY_QOS, history depth of 1, history kind of KEEP_ALL_HISTORY_QOS, and reliability of RELIABLE_RELIABILITY_QOS. The publisher is configured to only send one DDS message on startup.
I am seeing an intermittent issue where the publisher is up and running, and then the subscriber is started (late joiner). Sometimes, the subcriber does not receive the latest (and only) DDS message. Because only one message is transmitted, the subcriber does not receive any data. I do not see any data for the topic in DDS Spy. If I restart the publisher, the problem corrects itself and the subscriber receives the one message. If I then restart the subscriber (late joiner again) while keeping the publisher alive, the subscriber again successfully receives the one message even though the data had already been published some time ago due to it's durability.
I do not believe this is an issue with the durability settings, because I have also encountered it when the publisher is periodically sending data, there is no durability set, and the reliability is still RELIABLE_RELIABILITY_QOS. In this case the subscriber does not receive the first message published after it has started, but receives all subsequent messages.
Has anyone else experienced this behaviour?
Thanks,
Will
I was able to narrow down the problem for the volatile data I was publishing, but not the transient local data. I have not been able to recreate the problem using transient local data. In the case for volatile data, I can reproduce the problem and these articles helped resolve it:
https://community.rti.com/forum-topic/dynamic-data-writing-seems-need-setup-time
https://community.rti.com/kb/why-does-my-dds-datareader-miss-first-few-samples
The missed volatile messages were due to the reader not yet being discovered by the writer (the writer not completing it's initialization prior to it attempting to send data). Therefore what was observed is expected system behavior. Since it's volatile, once the discovery does happen the data isn't sent because the writer doesn't care about this late joiner (which is really a late discovery). All the transient local data that was sent arrives as expected even with no delay between creation of the data writer and attempting to send data.
Hello William,
Are you indicating in the second post that things are working as they are expected to? Also, when using reliable communications, are you setting any other parameters other than RELIABLE_RELIABILITY_QOS? Please look at the documentation on how to setup the reliability parameters. Also, you can look at the settings we suggest with our builtin QoS Profiles for reliable data.
Bert
Yes Bert it appears everything is working as expected now, thanks. I was trying to recreate the problem of missing messages using transient local data as indicated in my first post, but have not been able to do so. I'll keep an eye on it, but it's possible when I had first seen it, my application was actually configured for volatile instead of transient local, but I can't confirm that.