0

and subsequently obviously to read/take the topic. The problematic topic is published under BuiltinQosLibExp::Generic.KeepLastReliable.TransientLocal policy and the message is fired only once at the startup of the publisher application. Few things to consider:

Im not using this policy and taking the default policy configuration in code

dds::sub::qos::DataReaderQos tempQos = inSubScriber->default_datareader_qos();
m_EntitySpecReader = new dds::sub::DataReader<XXX_ICD::Entity_Specification_DT>(*inSubScriber, topicLocal, tempQos, m_EntitySpecListener);

from subscriber

  • The problem is not Firewall or some connection issue, as I know to receive other cyclic topics without any problem.
  • It is frustrating that I see this topic if Im trying to monitor either with rtiddsspy or RTI administration console.
  • Last bullet and most frustrating, when I actually felt stuck, is that I have a listener configured with all available callbacks and I thought to receive if not the data at least some callback clue regarding the possible mismatch, lost, something .... but it keeps silence no matter what Im trying to do :)

Will be more than happy to understand if somebody has an answer or potential direction to check :)

user9908830
  • 91
  • 8

1 Answers1

0

You are using the default QoS for your DataReader. This means that its Durability policy is VOLATILE. Even though the DataWriter is configured as TRANSIENT_LOCAL, it will not deliver "old" samples to your DataReader since it is not requesting those due to its volatile durability. In this context, "old" samples are samples that were written before the DataWriter discovered the DataReader.

Things should start working as expected when you configure your DataReader with a Durability policy as TRANSIENT_LOCAL as well.

If you instrumented a Listener on the DataReader, it should show you that a match has taken place though, or that it has failed. If you implemented both the on_subscription_matched and on_requested_incompatible_qos callbacks, then at least one of those two should fire if you have both applications started and if they are able to discover each other.

Since you discovered that the problem was a type mismatch, I wanted to show how the AdminConsole tool could have helped you finding that. Reproducing your issue, this is what it showed:

AdminConsole Type Mismatch

Reinier Torenbeek
  • 16,669
  • 7
  • 46
  • 69
  • HI Reinier, actually I have tried it with listener without success. Nor data neither mismatch or any other callback. This is my code 'tempQos.policy().kind(dds::core::policy::DurabilityKind::TRANSIENT_LOCAL)' . What do you think ? – user9908830 Mar 09 '21 at 08:13
  • Are you able to see both Participants and their DataWriter/DataReader in Admin Console and are they connected matching as expected? And did you double check that you are using the correct Topic name? – Reinier Torenbeek Mar 09 '21 at 12:46
  • Eventually I found a problem, it was a string parameter of the topic. In IDL it was configured without specific length. The publisher had generated code with "unbounded support" flag and I in subscriber had generated it without. Each side received string with different size, one just string and other string<255>. The strange thing here that this mismatch didn't trigger subscriber's listener mismatch callback, but for now this is another story :) Thank you for your help . – user9908830 Mar 09 '21 at 13:05
  • Good to read you found the cause. This is not a QoS mismatch and will therefore not trigger the associated callback. There is no callback defined for type inconsistencies, but AdminConsole could have helped you, like I showed in the screenshot that I added. – Reinier Torenbeek Mar 10 '21 at 00:42