These reproducers are just one sender that sends as fast as it can and one receiver that slowly processes those messages (and will therefore quickly get overloaded). However, the limited KEEP_LAST capacity should mean that most of the incoming messages should just get dropped
Run RouDi, then both bug_reproducer and bug_reproducer_rcv together with the provided cyclonedds.xml (which enables shared-memory communication and nothing else
Expected behavior
Nothing to see, or maybe errors on the sender side that the receiver was unable to receive messages
Actual behavior
An unending stream of
DDS reader with topic rt/reproducer_topic : iceoryx subscriber - TOO_MANY_CHUNKS_HELD_IN_PARALLEL - could not take sample
on the receiver side.
Additional information
If I understand it correctly, the error message states that the receiver is holding on to too many samples (>256, I believe). Which is strange, considering that the KEEP_LAST policy should limit the reader to at most 10 samples, we should never even get near 256.
Is it possible that the iceoryx samples don't get freed properly if they are dropped from the input queue?
Bug report
Required Info:
Steps to reproduce issue
Build the two example programs in the attached archive bug_reproducer_cpp.tar.gz
These reproducers are just one sender that sends as fast as it can and one receiver that slowly processes those messages (and will therefore quickly get overloaded). However, the limited KEEP_LAST capacity should mean that most of the incoming messages should just get dropped
Run RouDi, then both
bug_reproducerandbug_reproducer_rcvtogether with the provided cyclonedds.xml (which enables shared-memory communication and nothing elseExpected behavior
Nothing to see, or maybe errors on the sender side that the receiver was unable to receive messages
Actual behavior
An unending stream of
on the receiver side.
Additional information
If I understand it correctly, the error message states that the receiver is holding on to too many samples (>256, I believe). Which is strange, considering that the KEEP_LAST policy should limit the reader to at most 10 samples, we should never even get near 256.
Is it possible that the iceoryx samples don't get freed properly if they are dropped from the input queue?