For the persistence service there is a "restore" xml setting that can be set to 1 or 0 that specifies whether or not topic data from previous session is restored on startup.
I would like to use just one persistence service and have the previous session data for some topics to be restored on startup (as if 'restore' is set to 1) while the previous session data for other topics not to be restored on startup (as if 'restore' is set to 0).
Is there a way to do this in the xml settings or programmatically? If not is there an easy work around to get the desired behavior?
Thanks!
Jake
Hello Jake,
It is not possible to use the restore option per topic, as it affects all the persistence storage that is used to store the received samples. However, depending on your use case, you can perform two possible actions that could help you to suit your use case.
If you need to store all the data, including samples that you don't want to restore when you restart persistence service, you can execute two persistence service instances. With the right configuration, you can store samples from the topics that you want to restore in one instance, that will have the property restore = 1, and the samples that you don't want to restore would be stored by the second persistence service instance, that would be configured with the option restore=0.
A second option would consist of not storing the samples from the topic that you don't want to restore. To do this, you can filter and deny the samples that belong to those topics. The following code snippet shows how to filter samples to do not accept samples from a topic:
<persistence_service name="test">
<participant name="participant">
<persistence_group name="group">
<deny_filter>TopicName</deny_filter>
</persistence_group>
<participant>
<persistence_service>
Does any of these options suits your use case? Please let us know if you need any further information.
Regards,
Manuel
Hi Manuel,
For the time being I would like to see if there is a way to stick with a single persistence service instance but it sounds like it would definitely be a good option in the future for when I opt to incorporate more persistence service intances.
Regarding option 2, I don't think that will meet my use case since the instances I want to have configured with restore=0 still need to be sent to late joiners by the persistent service while the persistence service is up and running, but the only difference is I want the persistent service to not restore the values from the previous session when the persistence service is shut down and brought back up.
It sounds like if all else fails my options would be to consider either adding processing logic to my code to filter out this initial data where needed or to go with option 1 if it is feasible to use another persistence service instance.
Would it be possible though to have a single persistence service with restore=1, but to have some persistence writers configured to not send out just that initial restore data? Or maybe to have the readers configured to ignore just that initial data? I think that this would be the best solution for my use case.
Thanks,
Jake
Actually, another idea I am considering would be to have a single persistence service with restore=1, but to have the instances I don't want to persist between sessions deleted when I shut down my entire application (for my use case the persistence service will not outlive the application).
This may be the best approach if I can ensure that the deleted instances are not only deleted from my application but also erased in the database during shutdown. Is this behavior something I can configure through xml or programmatically?
Thanks,
Jake
Hello Jake,
First of all, I have been investigating the scenario that you described and reproducing a similar one. The best option seems to use two Persistence Services. You could use one to store the data that you want to be available after finish the Persistence Service execution, and the second one would store the data that you don't want to persist.
I have attached an example configuration based on the Persistence Hello World example provided with RTI Connext DDS. The XML attached has three persistence service configurations and I considered the topic DoNotRestoreTopic, as the topic that you don't want to restore when you restart Persistence Service.
The first configuration, called PersistenceServiceExample, is the one used to restore the sample of the topics that should be available after restarting Persistence Service.
The other two configurations are used for the topics that you don't want to restore after restarting Persistence service. Those configurations are:
- PersistenceNoRestore: This configuration will make Persistence Service store the data that you don't want to restore when Persistence Service is restarted, so you could access to this information reading the Persistence Storage even if you stop Persistence Service. However, the option restore is set to 0, so this data will not be sent after restart Persistence Service and the data would be deleted from the persistence storage.
- TransientPersistenceService: This configuration is used to do not store the samples that belong to topics that should not be sent after restart Persistence Service. Please note that this configuration requires that the DataReaders durability QoS should be adapted to match with TRANSIENT_DURABILITY_QOS. This configuration is not storing data for the topics that should not be sent after restarting the application in any persistence storage.
I added comments in the XML file to explain all the relevant information of the XML configuration file. Please let me know if something is not clear.
That being said, regarding the other option that you indicated to configure the Persistence Service writer to not send the initial data, or make the readers ignore that initial data, it is not possible to do that. The filter in the XML Persistence Service configuration file is applied to all the persistence group. This affects both the DataReader and the DataWriter. You could filter out the sample from certain topics both for DataReader and DataWriter, but not independently (you can see this in the attached XML configuration file).
If you try to filter the samples at your application DataReader's side, the problem is that you could not know which samples were read before and after restart Persistence Service.
Finally, about delete the samples when shutting down the application, you would need to access the database/persistence storage file and delete those samples manually, but you could not perform this through XML configuration of Persistence Service. You can create your own application/script that performs this task.
I hope this clarifies your questions. Please let me know if you need any further information.
Regards,
Manuel
This sounds like it will be the best option to have a separate persistence service. It may also be beneficial for fault tolerance reasons since if one persistence service goes down then not necessarily all topics will be affected. I will look into your example soon and let you know if I have any questions.
Thanks,
Jake