Who writes NOT_ALIVE_NO_WRITERS sample?

3 posts / 0 new
Last post
Offline
Last seen: 6 years 6 months ago
Joined: 06/10/2014
Posts: 49
Who writes NOT_ALIVE_NO_WRITERS sample?

Hi,

I've been running some tests with lan disconnects.  I have a simple scenario with 2 computers each running a DDS application with a single participant. They discover each other and can publish/receive samples of a single keyed topic. When the lan is disconnected, I see a sample on the bus with the instance state set to  "NOT_ALIVE_NO_WRITERS".    I assume the local pariticpant is responsible for publishing this sample but what if I have 2 processes with separate participants each subscribed to the same topic. Does each participant publish a "NOT_ALIVE_NO_WRITERS" sample when the lan is disconnected?  When the lan gets reconnected, I assume the "ALIVE" instance comes directly from the publishing participant (remote) and not the local participant.

Thanks for any insights.

Anne

Organization:
Juanjo Martin's picture
Offline
Last seen: 1 year 8 months ago
Joined: 07/23/2012
Posts: 48

Hi Anne!

Very interesting question! First, let me paste here some notes from the documentation of sample_info.valid_data.

----

    Indicates whether the DataSample contains data or else it is only used to communicate a change in the instance_state of the instance.

    Normally each DataSample contains both a DDS_SampleInfo and some Data. However there are situations where a DataSample contains only the DDS_SampleInfo and does not have any associated data. This occurs when the RTI Connext notifies the application of a change of state for an instance that was caused by some internal mechanism (such as a timeout) for which there is no associated data. An example of this situation is when the RTI Connext detects that an instance has no writers and changes the corresponding instance_state to DDS_NOT_ALIVE_NO_WRITERS_INSTANCE_STATE.

    The application can distinguish whether a particular DataSample has data by examining the value of the DDS_SampleInfo::valid_data. If this flag is set to DDS_BOOLEAN_TRUE, then the DataSample contains valid Data. If the flag is set to DDS_BOOLEAN_FALSE, the DataSample contains no Data.

    To ensure correctness and portability, the valid_data flag must be examined by the application prior to accessing the Data associated with the DataSample and if the flag is set to DDS_BOOLEAN_FALSE, the application should not access the Data associated with the DataSample, that is, the application should access only the DDS_SampleInfo.

----

The instance_state is the current state of the instance. The state can change if it is disposed, if all the DataWriters are gone or if suddenly it becomes alive. That is independent of the actual data sample that you are reading. I mean, it is not the instance_state at the point the data was received -> it is the current instance_state.

It may happen that we have no data in the queue but RTI Connext wants us to know about the change in the instance_state for a given instance (maybe it detected that all the remote writers are gone?). In order to do that, it puts a new sample in the DataReader queue, with sample_info.valid_data = FALSE. This means, that it doesn't make sense to read the content of the actual data but you have interesting information in the SampleInfo. That is why even though we don't have any remote applications, sometimes on_data_available is triggered (we are notified by the middleware). So, the local Participant puts a sample in the local DataReader to notify about the change.

Take into account that different Participants can realize about DataWriters leaving the system in different times. Each of them put this meta-data sample in their DataReader queue when they realize about the change in the instance_state.

Let me know if you have any other question.

Juanjo Martin
Applications Engineer
Professional Services Group
Offline
Last seen: 6 years 6 months ago
Joined: 06/10/2014
Posts: 49

Hi Juanjo,

Thanks for the good explanation! This makes sense to me now.

Anne