Deleting data writer with DDS::PERSISTENT_DURABILITY_QOS

We are working on an application that is meant to load its configuration from the DDS persistence service. However, we are struggling to load data into the persistence service reliably. 

For the initial phase, we wrote an small loading application that reads static configuration from a file and then publish the information to some configuration Topic with data writer durability QOS policy set to DDS::PERSISTENT_DURABILITY_QOS. The idea is when the main application starts it will subscribe to the same topic and read this configuration information from the persistence service rather than the initial loading application. 

The issue we are facing during initial loading phase is, as soon as the loading application that reads data from the file and publish stops, the sample instance_state is set set to DDS::InstanceStateKind::NOT_ALIVE_DISPOSED_INSTANCE_STATE even though the loading application did not dispose anything. Therefore, when the main application starts it sees only the disposed samples.

We followed the example shown in the provided sample application and before the loading application exits it deletes the data writer associated with the configuration topic  and then the topic itself. Then at the domain participant level it calls the "delete_contained_entities" and then using the fatory method deletes the participant too.

We noticed, instead of closing the loading application explicitly if we disconnect the host where the loading application is running from, then the sample's instance_set is kept to DDS::InstanceStateKind::ALIVE_INSTANCE_STATE. Similar observation have been made when we shutdown the persistence service first and load it later after the loading application is closed. The samples state are maintained DDS::InstanceStateKind::ALIVE_INSTANCE_STATE. In those instant, data can read from the persistence reliably. Therefore, deleting the data writer obviously influence the state change.

It looks like the deleting the data writer from the topic triggers the change of the instance_set for the samples. The question is, what would be the clean way to close the loading application so its terminatin does not alter the state of the  floating sample's instance_set. In other words, if it is possible to keep instanse_state unchanged when persistence service writer writes the samples back to the late joining applications. 

Regards,

Jamil A Zaman
Software Engineer
Exelis C4i Inc.