Reliable Data writer dropping messages due to slow Best Effort reader

No—the presence of a reliable reader does not turn the Best Effort reader into a reliable one. A reliable DataWriter can match both kinds of readers, but it runs the reliability protocol only for its reliable matches. The slow Best Effort reader does not ACK samples or cause retransmissions.

What you are seeing is instead a consequence of the reliable writer’s shared writer-side resources, especially its RTPS reliable-writer send window.

With a RELIABLE DataWriter and KEEP_LAST history:

• The writer may overwrite old history samples when its history depth/resource limits are reached—even if they have not been acknowledged.
• However, if data_writer_protocol.rtps_reliable_writer.max_send_window_size is finite and that send window becomes full, write() can block until samples are protocol-ACKed by the reliable reader(s), or until reliability.max_blocking_time expires.
• Once that timeout expires under KEEP_LAST, Connext can replace older samples in the writer history. If the reliable reader has not received those samples yet, it will observe loss.

So the slow Best Effort reader’s full receive queue should cause that reader to drop data; it should not directly hold up reliable delivery. But its traffic can still consume shared transport/network capacity, CPU, or writer scheduling capacity enough that the reliable reader falls behind. Then the writer’s finite send window/history limits cause the reliable reader to lose older samples.

That is correct. Do not expect it to participate in reliable ACK/NACK behavior.

For a RELIABLE + KEEP_LAST writer, configure the reliable-writer send window as unlimited if your design accepts bounded loss of older samples under overload:

With the send window disabled, a RELIABLE + KEEP_LAST writer does not block because of a full send window. It can still overwrite old samples once its configured history/resource limits are reached—so this protects the publisher’s timing, not every historical sample.

If the reliable reader must receive every sample during a burst, KEEP_LAST depth 200 must cover its maximum backlog:

[ \text{required depth} \ge \text{publish rate} \times \text{maximum reliable-reader delay} ]

Also check RESOURCE_LIMITS.max_samples and max_samples_per_instance; those can cap the effective writer cache independently of HISTORY.depth.

If the slow reader is on a constrained link, consider one of these architectures:

• Publish a separate Best Effort topic/DataWriter for that consumer.
• Use a separate transport/interface, multicast group, or traffic class for the Best Effort stream.
• Reduce the Best Effort reader’s requested rate using TIME_BASED_FILTER.
• Use a bridge/Routing Service to decouple the slow consumer from the primary reliable path.

This avoids the Best Effort stream consuming enough shared network or host resources to make the reliable reader fall behind.

You cannot simultaneously guarantee every sample to the reliable reader and guarantee that the writer will never be delayed or constrained by that reader. If the reliable reader cannot keep up indefinitely, you must choose between:

• Strict delivery: RELIABLE + KEEP_ALL, sufficient resources, and possible writer blocking; or
• Bounded/latest-value delivery: RELIABLE + KEEP_LAST, sufficiently large depth, and acceptance that older samples may be overwritten during overload.

For your stated goal—do not let the slow Best Effort reader interfere—the Best Effort reader is already configured correctly. Focus on the reliable writer’s send-window configuration, writer-history sizing, and isolation of shared bandwidth/resources.

Sources:

• Reliable Delivery Model
• Writing Data
• 5. Basic QoS — RTI Connext Getting Started documentation