Hello,
My scenario involve a datawriter and a datareader each one runs on its own host and exchanging topic instances through network.
I want the datareader side to be able to:
- Allocate resources (working processes for example) on creation of instances because the datawriter issues write keyed samples
- Free the resources on destruction of instances because the datawriter issues unregister or dispose (doesn't matter) of keyed samples, once they are created
Until now, no difficulty by reading status instances on the datareader side.
Now, while some instances has been already created and maintained ALIVE by the datawriter and while the corresponding resources has been created by the datareader side, I want the datareader side to be able to:
- Free the resources if there is a network disconnection of the datawriter side > 10 seconds
- Reallocate these resources if the network is connected again
... and without intervention of the datawriter.
To do that I use automatic liveliness with lease_duration of 10s.
With that, the datareader side:
- Is able to detect that the datawriter becomes not alive and alive again using datareader listener or read status condition.
- Moreover, because it keep samples data and infos in memory, it is able to list the instances issued from the disconnected or reconnected datawriter.
Despite that, it seems that a datareader event miss to be able to achieve the goal completely.
Here is the issue:
- The writer side creates (writes) an instance:
---> The reader side sees creation (ALIVE) of the instance and allocates corresponding resource
- The network is disconnect 10 seconds:
---> The reader side sees the datawriter becoming not alive (because of automatic liveliness)
---> It frees the resource corresponding to the instance issued form the datawriter
---> (note that the status of the instance inside the datareader become NOT ALIVE NO WRITER)
- The network is connected again:
---> The reader side sees the datawriter becoming alive (because of automatic liveliness)
---> It reallocate the resource corresponding to the instance issued from the datawriter (because it keep the sample data and info in memory)
- The writer side deletes the instance (unregister or dispose):
---> No event on the reader side ! But it should frees the resource ! what do not I understand ?
How can I catch a reader event telling me that the writer unregisters or disposes an instance, after the writer has been temporarly not alive ?
Hi,
There is a known issue in which instances that are still registered and published by a DataWriter that lost liveliness do not transtion to the ALIVE state on the DataReader once liveliness is recovered. Because the instance is in a NOT_ALIVE state when you dispose or unregister explicitly, you do not get notified of a state transition. Our internal issue number is CORE-3018. This is something that we will be looking into for future releases.
There is a way to make your use case work but it will require using dispose semantics on the DataWriter side when you want to delete an instance explicitly. This means that instances will transition to NOT_ALIVE_NO_WRITERS when there is disconnection and they will transtion to NOT_ALIVE_DISPOSE when the DataWriter disposes of the instance explicitly.
To make your use case work you will also need to change the reader configuration as follows:
reader_qos.protocol.propagate_dispose_of_unregistered_instances = TRUE
reader_qos.protocol.propagate_unregister_of_disposed_instances = TRUE
Also, change the DataWriter QoS as follows:
writer_qos.protocol.serialize_key_with_dispose = TRUE
By default, once an instance transition to NOT_ALIVE state (NOT_ALIVE_NO_WRITERS or NOT_ALIVE_DISPOSE) it will not transition to a different NOT_ALIVE state by receiving a dispose, for example.
Setting the previous QoS values to TRUE will allow you to make the transtion from one NOT_ALIVE state to a different NOT_ALIVE state.
Regards,
- Fernando
Thanks a lot Fernando.
Another question about liveliness:
Can I be sure that a datareader listener on LivelinessChangedCallback will catch all alive/not alive events from connected datawriters ? I wonder that because the DDS_LivelinessChangedStatus talk about last_publication_handle...
Thanks again.
Hi,
Although the DDS specification does not require calling LivelinessChangedCallback for each liveliness event, our implementation (Connext DDS) calls LivelinessChangedCallback for each event.
The only thing to take into account is that we cannot guarantee that the behavior will not change in the future. So far this has not been the case.
- Fernando
Hi
Yesterday, I falled into another trouble...
When I get two datareader (same participant and same subscriber) connected to the same datawriter and this datawriter lost its liveliness, both listener LivelinessChangedCallback are not called as I expected. It seems that the engine "randomly" choose a datareader target...
Do I miss something ? I there a way to have both datareader callbacks called ?
Thanks a lot for your precious help.
Boris.
Hi Boris,
You are running into a product issue, CORE-7626, for which I do not have a clear workaround without knowing more about your use case. Why are you trying to create multiple DataReaders within the same Participant?
Regards,
- Fernando
Hi,
I create multiple DataReaders because there is different software module or plugins loaded on demand depending on the user's actions and these DataReaders may be configured with different ContentFilteredTopics
Subsidiary question: does these different ContenFilteredTopics are taken into account by DataWriters when DataReaders are attached to the same participant/subscrier ?
As a workaround, I am trying now to post an internal process notification (using a third-party C++ framework) to distribute the liveliness events to my generic software layer managing the native DDS DataReaders. I hope this will solve my issue and not create new ones !
Thank you for your reactivity.
Boris.
Hi Boris,
Sorry for my late response. DataWriters will take into account ContenFilteredTopics for DataReaders attached to the same participant/subscriber.
Regards,
- Fernando