Problem with coherent update

3 posts / 0 new
Log in or register to post comments
Last post
Wed, 04/23/2014 - 06:04
#1
Dusko Susa
Offline
Last seen: 10 years 7 months ago
Joined: 04/23/2014
Posts: 4
Problem with coherent update

I am working on implementing some kind of DDS wrapper library. I want to add the support for the coherent update to this library. But, for some reason it doesn't work as I would expect. When I call end_coherent_changes, the return code value is OK, but the following trace is written to the output window:

[D0005|Pub(308)|END COHERENT CHANGES]PRESPsService_writerSampleListenerOnQueueUpdate:!get pres psWriter
[D0005|Pub(308)|END COHERENT CHANGES]WriterHistoryMemoryPlugin_addEndCoherentChangeSample:empty coherent set

As the result, I have one additional sample in my reader cache (all field values are set to 0). Other valid samples are also available for the reader and I can read them, but the problem is the last entry (with all 0s). My implementation is inspired with the example from RTI documentation (http://community.rti.com/kb/example-code-coherent-presentation). 

I would be grateful, if I could get some explanation for this behavior. Besides that, I would also like to understand why there is no error when I call end_coherent_changes if something is wrong.

Top
Fri, 05/23/2014 - 16:49
rose
rose's picture
Offline
Last seen: 3 years 5 months ago
Joined: 08/22/2011
Posts: 148

Hello Dusko, 

I noticed that our support team is hard at work on this case in our support portal.  When it's resolved, please feel free to post the resolution here for other people to view.  

Thank you!

Rose

Top
Mon, 05/26/2014 - 01:34
Dusko Susa
Offline
Last seen: 10 years 7 months ago
Joined: 04/23/2014
Posts: 4
Answer from RTI support:
 
1) Upon HEARBEAT send, we make an internal callback to a function that checks if LIFESPAN is not INFINITE and then:
 a) If it is infinite, it does nothing.
 b) If it is not infinite, it looks for expired samples and remove them.
 
As a consequence of CORE-6203, we fail before the check. We still send the HEARTBEAT, but we are potentially missing the opportunity of pruning the samples. If you are not using LIFESPAN, the error has not impact in  your application's behavior.

 

2) CORE-6203 issue only affects to the HEARTBEATs that are sent as a result of the piggyback mechanism (it does not affect to the periodic HEARTBEATS).

 Consequently, there is a workaround which, depending on your requirements, could we applicable. Since the error is shown when we try to prune lifespan expired samples upon piggyback heartbeat, we could disable piggyback heartbeats (and rely only on the periodic ones) by using:

<datawriter_qos>
  ... 
   <protocol>
      <rtps_reliable_writer> 
         <heartbeats_per_max_samples>0</heartbeats_per_max_samples> 
      </rtps_reliable_writer> 
   </protocol> 
</datawriter_qos> 

 

Top