How to avoid dropping messages in broadcast channels

[shsms]

What's needed

• Have a way to avoid dropping messages in broadcast channels #20

When a broadcast receiver is not getting consumed from fast enough and its buffer has filled up, as new messages arrive, older messages in the receiver's buffer start to get dropped.

In some cases, we might not want messages to get discarded, and instead want the sender to wait for the receiver to drain before it can send further messages to the channel.

Once we decide how we want to solve this, we can close this discussion and edit #20 to have the final proposal so someone can implement it.

Proposed solutions

Solution 1: Block receivers if receiver buffers are full

Add an optional block_on_full boolean parameter to the new_sender method of the Broadcast channel, which defaults to False.

When true, calls to the send async method will not complete until the value has been sent to all the channels.

(original proposal from #20)

Note

This is related to:

• Implement SyncSender and AsyncSender #76

For sends that we know they can't block (because a buffer is used to store it and the message will be dropped if the buffer is full), there is no need to make it async, which has a performance impact. We could make async only sends that can block.

Solution 2: Allow senders to query if there are active receivers

Receiver behaviour

When a receiver is not being consumed from for a certain duration, the channel stops sending to it. If the receiver is awaited again, it gets treated like a new receiver, starting with an empty buffer, and respecting resend_latest.

Sender behaviour

The send methods don't block, so it is the same behaviour as now, but the sender has a property and an async method which can be used to prevent wasteful work, like this:

if not sender.has_active_receivers:
    await sender.wait_for_receivers()

This would prevent the sending side from doing active work, and possibly stop receiving from its upstream and stop work on that level as well.

So channels would finally transmit information about receivers to the sending side, if they are interested.

[shsms]

So, would this be a complement for #20?

Wow, I had completely forgotten that was there. Anyway, I think this current proposal offers more flexibility, considering that we haven't had a use case in the past few years where we can't discard some values. Unless we have use cases like writing to disk or reporting to external parties, where it is absolutely critical that we don't drop messages. So maybe we should keep that issue open but separate.

BTW, I don't think this needs to be assigned to v2, as it can be implemented as a new feature (in v2 we could change defaults, like making this mode of working the default).

I agree; I put it under 2.0 only to signify that this is not super urgent. I've called it untriaged instead.

[shsms]

Yes, broadcasts with ack are so tough. I guess the two options are:

• stop sending if none of the receivers are active.
• stop sending if any of the receivers are not active.

My first thought is to extend the above design by adding a sender.has_inactive_receivers property to support the second case.

[shsms]

Then the receivers can be configured to become inactive either after an interval, or as soon as they become full. And the sender features and receiver features would provide a lot of possibilities.

[llucax]

Solution proposed originally in #20 by @shsms:

Add an optional block_on_full boolean parameter to the new_sender method of the Broadcast channel, which defaults to False.

When true, calls to the send async method will not complete until the value has been sent to all the channels.