I have a problem with instance inconsistency between multiple data writers when updating an instance from another data writer. I suspect the problem is similar to the following forum post https://community.rti.com/forum-topic/durable-writer-problem
Application 1's data writer will publish a key instance, application 2 will recieve the instance and update one of the fields of the instance, all currently running applications recieve the last update, application 2 is terminated, any newly launched applications recieve the instance from application 1, and not the updated instance from application 2. No applications recieve a dispose message from
Using RTI's 5.3, the QOS settings for the data writers are set to transient local durablity, shared ownership, keep all history, and reliable.
I suspect the data writer in application 1 is not listening for updates from other data writers, and therefore never gets updated. What would be the best approach to have the data writer in application 1 to store the updated field from the other data writer?
In DDS, DataWriters do not receive data from each other. DataWriters only know about and have values for the instances that they send. Different DataWriters of the same Topic don't sync up what instances exists between them.
It's not clear from your description the layout of your system. Do your applications 1 and 2 have DataReaders subscribing to the same Topic as being sent by the DataWriters?
How do you mean that "application 2 will receive the instance"? Does it subcribe to the topic from application 1 using a DataReader?
What does it mean that "application 2 updates one of the fields of the instance"? Do you mean that application 2 publishes data for the topic using a DataWriter?
For TRANSIENT_LOCAL durability, when an application is terminated or the DataWriter is otherwise deleted, any stored data is gone and no longer will be available to be sent.
If you want data for an instance to exist independent of the lifecycle of the original DataWriter, then you will have to deploy a Persistence Service and use either TRANSIENT or PERSISTENT Durability.
Finally, I'm not sure what you are stating with "No applications receive a dispose message from" That sentence seems to be cut off...and I'm not sure what you are trying to say with about the operation of DDS with that statement. What do you expect to happen?
Thanks for responding Howard, for a better picture, let answer your questions regarding the setup.
Yes, application 1 and 2 have data readers for the same topic being sent by the two data writers.
Application 2 subscribes to the topic and receives a message from application 1.
Application 2's data reader on recieve, modifies a field and republishes the message on it's data writer.
I concur that the data writers do not sync up with the instances as they're not subscribing to the topic, but is there a way to have the data writer get updated with a new instance without deploying the persistence service?
Sorry for the cut-off not sure what happened there. I do not see a dispose message from the application 2's data writer when it is closed down. I would expect to see one but I do not. This maybe my configuration and QOS settings. This matters to me from an observer stand point, it recieves the latest update from application 2 but subsequent data readers after application 2 shut's down will have a difference value of the message.
That concept does not exist. DataWriters aren't updated with values of instances by other DataWriters. DataWriters only manage instances that are passed to it through user code via method calls on a DataWriter object...e.g., write() or register_instance(). Again, DataWriters are never sync'ed with the data sent by other DataWriters.
What is it exactly are you trying to do?
Why do you expect to see a dispose message when shutting down an application (deleting a DataWriter)? Whether a DataWriter will dispose of it's instances when its shutdown is configured by the WriterDataLifecycle QoSPolicy...specifically the "autodispose_unregistered_instances" flag. When a DataWriter is deleted, all registered instances are unregistered. This flag controls whether or not they are first disposed. In Connext DDS 6.1, this flag is false by default, so deleting a DataWriter will NOT dispose of any instances that are registered by the DataWriter. Prior to Connext 6.1, the flag was true...so the behavior did change between versions. What version of Connext DDS are you using?
The only way to do this is to use Persistence Service. A DataWriter does not maintain the data sent by other DataWriters. Only the Persistence Service can do this.