My understanding is that DDS DataWriters communicate CacheChanges to the HistoryCaches of the associated RTPS Writer. This CacheChange is then propagated to the mapped RTPS Readers before notifying their associated DDS DataReaders.
From the above statement, there are queues (the HistoryCache) on the RTPS Writers and Readers.
Hello,
In my project, I need sometimes to destroy a subscriber and all its related datareaders, to instanciate them again after with the same parameters, without changing anything with participant.
The environment is .NET 4.0 / RTI DDS 5.1.0
Here is the sequence :
---subscriber intialization---
sub = participant.create_subscriber(SubQos, ...);
...
DataReader reader = sub.create_datareader_with_profile(SomeContentFilteredTopic, ..., DDS.StatusMask.STATUS_MASK_ALL);
...
reader.enable();
sub.begin_access();
I'm told that DDS maintains a reference to DTOs created when using the example code here:
code
After a few minutes reading data from a topic, the subscribing program unexpectedly terminates as if someone decided to simply stop it. What could cause a subscribing program to terminate by itself? I had originally thought that maybe it was a set limitation of the trial license (since at termination, the licensing information is displayed), but the problem remains with the full license. Data is received with a couple losses here and there. Perhaps the problem is obvious, but I am new to DDS. Has this happened to anyone else, and how did you solve it?
I am writing a public transport system using RTI DDS, but I met a strange problem:
This situation works well:
1. start a passenger subscriber with content filtered topic
2. start publishers
3. the passenger subsriber gets the messages well
4. start a second passenger subscriber with a different content filtered topic
5. the second passenger subscriber gets the messages well
This situation has problem:
