Why RabbitMQ client does not support sending flow command from a client to a server?

[antpata]

Is your feature request related to a problem? Please describe.

To be able to implement priority queues with quorum queues and push delivery (not get), message delivery need to paused when several priority queues has messages available at the same time. Currently flow control is supported from server to client but not from client to server per a channel.

This is not a problem if a message handler fast (< 1sec) and quite low priorization ration (like 5:1) between high and low queues is OK. But in case a when a low priority queue need to be stopped for minutes to handle high priority traffic on a slow message consumer then the push mode delivery is very problematic without a flow control. Currently it seems that polling with the get method is the only viable option to read from several queues in a strict priority order.

Describe the solution you'd like

To be able to pause a consumer or all consumers in a channel receiving messages from server. I guess that would be enabled if the flow method can be send from client to the server.

Describe alternatives you've considered

To be able to send BasicCancel for a consumer and re-enable it by calling consume for the same consumer again when flow is resumed but the client seem not designed for that either. Client will leak some memory if this is done. _recordedConsumerTags in AutorecoveringChannel is not cleared by BasicCancel https://github.com/rabbitmq/rabbitmq-dotnet-client/blob/c69bf00fb7673f569763e2bf23dbc6bcc1cb462c/projects/RabbitMQ.Client/client/impl/AutorecoveringChannel.cs#L48C30-L48C52.

rabbitmq-dotnet-client/projects/RabbitMQ.Client/client/impl/AutorecoveringChannel.cs

Line 276 in c69bf00

public void BasicCancel(string consumerTag)

Additional context

This case happens for example when a consuming service is a reporting service. Reporting services tend to run long time and are quite resource intensive for other resources that they use. For that reason it is not always easy just setup a service per queue. Ideally one set of consumers would pull from several queues so that resource consumption is limited but resources are also optimally used.

[michaelklishin]

Because there is no such operation in the protocol, and no plans to add one. Manual application-driver flow control ended up being a failure and it was deprecated many years ago (at least around 2014 IIRC).

It is possible to cancel and re-add consumers dynamically but this usually does not work quite as smoothly as most people expect. Application-driven flow control is difficult to get right, prone to concurrency hazards when multiple channels or connections or instances are involved, and so on.
Use it at your own risk.

[antpata]

So last options that is left on the table is poll with get or allocate separate consumer resources for different priorities?
Poll would be OK with proper dynamic poll delay if long max message latency (>3 sec) is allowed. Of course message volumes must be low (<500 1/sec).
It would be better to get rid of message priorities all together for example using autoscaling if possible (it might be expensive or impossible).
Conclusion would be that it is hard to use RabbitMQ for throttling. Easiest solution seems to be just over allocate and under use consumer resources. Auto scaling will help if needed resources are auto-scalable.

Thanks, I is good to limit features to those that can be done right