With the default QoS for send window size, a reliable writer using KEEP_LAST history may block on write

Note: This solution applies to RTI Data Distribution Service 4.5c.

Applications that use writers with KEEP_LAST history may behave differently when built with 4.5c, compromising backward compatibility.  Previously, a reliable write would not block under default QoS, as its queue was allowed to grow in an unbounded way.  When writers were progressing faster than readers, this behavior could cause significant resource growth and throughput degradation when the writer was configured for KEEP_ALL operation and significant data loss when it was configured for KEEP_LAST.

Now, due to the addition of the default QoS for send window, a reliable write will be able to throttle itself to the progress of its readers automatically and, consequently, will block when the number of unacknowledged samples in-flight is greater than the send window, regardless of the size of the writer’s history queue resource limits.

This blocking happens not only for KEEP_ALL, but also KEEP_LAST; a blocked KEEP_LAST queue must wait for a sample to become acknowledged before proceeding, and as such is now subject to time-out of the blocked write.  Note that the DDS spec does allow writes to block when KEEP_LAST is used.  However, it does not behave the same as previous versions, and thus can adversely impact previous users.

For a workaround, if desired, the user can revert to the behavior of previous versions by setting both min_send_window_size and max_send_window_size to LENGTH_UNLIMITED.  This effectively turns off the send window feature and retains compatibility with earlier releases.


Experimenting with "News" or "RequestReply" exampe from RTI distribution, I try to reach a blocking behavior with KEEP_LAST and *_send_window_size, without success.

What are the other QoS settings to see a real blocking publisher?