getSubscriptionState() seems abnormal

[jhx2002]

Node1 has two publisher. Node2 has one publisher and two subscriber.

The subscribers and publishers are alive.

getSubscriptionState() sometimes return SUBSCRIBED, and sometimes return NOT_SUBSCRIBED.

and as a result, lots of messages are lost.

[mossmaurice]

@jhx2002 Thanks for raising this question. Could you post the code snippet here in the issue? Did you use iox::popo::SubscriberOptions::subscribeOnCreate and iox::popo::PublisherOptions::offerOnCreate to configure the publisher and the subscriber?

[jhx2002]

I use version 0.90, the code refer to examples/icedevery

[jhx2002]

void Sync::subdata(){ { iox::popo::SubscriberOptions sub_option; sub_option.queueCapacity = 10U; depthsuber = std::unique_ptr<iox::popo::TypedSubscriber > (new iox::popo::TypedSubscriber({"stamp", "img", "empty"}, sub_option) ); depthsuber->subscribe(); }

{ iox::popo::SubscriberOptions sub_option; sub_option.queueCapacity = 100U; posesuber = std::unique_ptr<iox::popo::TypedSubscriber > ( new iox::popo::TypedSubscriber ({"stamp", "posi", "quater"}, sub_option) ); posesuber->subscribe(); } }

[elfenpiff]

@jhx2002 To comprehend it fully here some questions.

1. Are the 3 publishers in your setup publishing on 3 different services or do some of them share a service and you have a multi publisher setup?
2. When does the SUBSCRIBE / NOT_SUBSCRIBE switch occur. In the middle of the communication or when you start one of the nodes? Does this occur when you restart Node1 for instance?
3. Could you retry your code with the current master (it should be API compatible). Do you observe the same behavior?

[budrus]

@jhx2002 When we introduced getSubscriptionState() we only supported one publisher for a topic. The SubscriptionState clearly indicated whether you are connected or not to this single publisher. This is still the case if you compile iceoryx with the option that only one publisher is allowed per topic. If there can be multiple publishers on a topic, the subscription state is no more 100% clear. We currently have a simple approach. If the subscriber calls subscribe, you will be in the state SUBSCRIBED as soon as the discovery loop recognized your wish. The discovery loop has a 100ms cycle. I.e. it can take up to 100ms from calling subscribe() to be in state SUBSCRIBED. Do you have this issue only during startup? On latest master and with our RC1 that we'll have tomorrow we introduced new options. Default behavior is to offer a publisher on create and to to the subscription for subscribers on create. You do not have to call subscribe() anymore if you do not disable this option. And we will be SUBSCRIBED when the c'tor returns. With this setup you would only loose samples if the history is not large enough for the late joining subscriber or if the subscriber has a queue overflow during runtime

[jhx2002]

Test with version 0.99. NOT_SUBSCRIBED state disappear.

But some messages are still lost.

[jhx2002]

// publish options iox::popo::PublisherOptions pub_options; // the publishers stores the last 10 samples for possible late joiners
pub_options.historyCapacity = 100U; pub_options.offerOnCreate = true; static iox::popo::Publisher puber({"stamp", "posi", "quater"}, pub_options);

// subscribe options void Sync::subdata(){ { iox::popo::SubscriberOptions sub_option; sub_option.queueCapacity = 500U; posesuber = std::unique_ptr<iox::popo::Subscriber > ( new iox::popo::Subscriber ({"stamp", "posi", "quater"}, sub_option) ); fmt::print("PoseMsg getSubscriptionState {}\n", posesuber->getSubscriptionState()); } }

// result: send pose 69 times, but receive pose 48 times

[elBoberido]

@jhx2002 is your question regarding the subscription state sufficiently answered? If yes, please close the issue.

The question regarding data loss is discussed in #668

[elBoberido]

@jhx2002 I assume that the question was sufficiently answered and close this PR. Feel free to open it again if this is not the case.