Subscriber joining late.

3 posts / 0 new
Last post
Offline
Last seen: 2 years 6 months ago
Joined: 10/11/2017
Posts: 9
Subscriber joining late.
AttachmentSize
File rti_test_qos_profiles.xml18.43 KB

Hi,

I'm based on RTI DDS  5.3.0 under Linux and Windows systems. I implement two separate components 1 Subscriber and 1 Publisher on 2 differents system as follow:

  • a single publisher publishing 2 topics (a big one of 2.25 MBytes and a 2nd small one of 10KBytes data size) every 33 msec during about 16 sec (ie. 500 times)
  • a single subscriber subscribing both topics. Subscriber must receive all data in sent order.

So, I implement a qos xml file based on "Generic.StrictReliable.LargeData.FastFlow" builtin QOS with KEEP_ALL_HISTORY_QOS/TRANSIENT_LOCAL_DURABILITY_QOS and datawriter.resources_limits.max_samples to 500.

 

In case of subscriber connected before data flow it's ok. The problem is in case of late joining susbcriber. Publisher cyclic write hang until the history is sent to the subscriber.

Is it normal that new subscriber impact the data writer (until blocking FooDataWriter::write method) ?

How can I proceed to retrieve history from susbcriber side while continuing sending new data from publisher side ? Which QOS policy must be modified ? (I attached to this topic my QOS file)

Thanks in advance.

 

Offline
Last seen: 4 weeks 7 hours ago
Joined: 02/11/2016
Posts: 143

Hey,

 

If you send the historical data alongside the current data, that would result in a lot of pressure on the reader (that will still need to receive all the historical data before it can pass along the new data to the receiving application since, as you mentioned, Subscriber must receive all data in sent order)

 

Do you need to receive historical data?

 

Good luck,

Roy.

Offline
Last seen: 2 years 6 months ago
Joined: 10/11/2017
Posts: 9

Hi, 

Thanks Roy for the prompt reply. Yes, I need to receive historical data. And subscriber can join whenever during the data flow. What surpises me, is the fact that during the historical data flow, provider's written requests (each 33 msec) hang until the end of the historical data stream sent to the subscriber. In fact in my case, what I need on subscriber side is to receive all data (current and historical data => no data lost) without disturbing provider written data flow (cyclic publication). I don't know how I can proceed and which qos parameters I have to set.

Regards

Patrice