Ask help from subscribers

4 posts / 0 new
Last post
Offline
Last seen: 1 month 2 weeks ago
Joined: 01/28/2022
Posts: 4
Ask help from subscribers

Hi,

Don't know if this is a right solution for this scenario, but let's say there is one publisher and one subscriber. At one point the publiser crashes, after it restarts, I assume it loses all the samples it published before. In order to rebuild the states, can it ask for the subscriber, which does not crash, to publish these samples it recevied? Or we should use the Presistence Service in this case?

Regards,

Peter 

Keywords:
Howard's picture
Offline
Last seen: 15 min 19 sec ago
Joined: 11/29/2012
Posts: 354

Well, it's unclear what exactly your use case is.  Where does the publishing application get the data that it published in the first place?  Can't it store any data that it needs on a disk in case of a restart?  What happens if the subscribing application crashes?  How many data samples/how much data is needed to "restore the state" of the publishing application?

The answers to the questions above as well as other details will determine the optimal way to use DDS to meet your system requirements.

But yes, your publishing application could subscribe to the data that it publishes, and then you could use a Persistence Service to automatically send any data that it has stored to the publishing application upon the startup of the publishing application. 

Offline
Last seen: 1 month 2 weeks ago
Joined: 01/28/2022
Posts: 4

Hi Howard,

Thanks for the reply. Maybe I should  ask the question in a different way: 

I am trying to understand the different use cases of the three presistent storage solutions: Durable Writer History, Durable Reader State, and Data Durability (using the Persistence Service). Our currently focus is to handle crashs and restarts of a DDS node (publisher or subscriber). It seems the first two options are the best fits for that kind of use cases, is that right? BTW, I heard the Persistence service will only support SQLite in the future. Is that going to affect the ODBC interface used by Durable Writer History and Durable Reader State?

Thanks,

Howard's picture
Offline
Last seen: 15 min 19 sec ago
Joined: 11/29/2012
Posts: 354

Durable writer history and durable reader state *are not* persistant storage solutions.  The Durability QOS used with RTI Persistance Service is a solution that will store published data to be automatically sent to new DataReaders.

However, the use of Durable Writer History with Durable Reader State and the Durability QoS can provide a higher level of resiliance against crashes in a system that uses DDS.  This is the chapter in the User's manual that discuss this topic.

As for your questions about SQLite/ODBC support, that's a question that's best answered by the RTI account team.  I will ask them to get back to you on that.