Pause message delivery from queue to consumers using management plugin

[Solcloud Dev]

Hello guys,

Would be nice if management plugin could add a button "Pause consuming" to queue detail after Purge.
This button will add boolean flag to target queue meaning that queue will be "pretending" there is no Ready message in queue.
This will effectively stop delivering "new" message to consumers, but unacked message and general communication with consumers would still be happening.
Only no new ready message after button click will be delivered to consumers (rabbit will pretend there is no ready message in queue for all consumers to pick).
And of course there should be way to reverse that button "Unpause consuming".
Also will be nice if that button can be operated using management plugin API.

It is kinda hack for rabbit to pretend there is no message even tho there could be many but I am guessing that will be easier to implement but I could be wrong.

Similar topics already discuss in these posts, but outcome is no paying customer requested this so no implementation, first feature mention is from January 2015
https://groups.google.com/g/rabbitmq-users/c/68-DPZN4b_Q
https://groups.google.com/g/rabbitmq-users/c/v1fR5ty0yII

I know I can do similar effect on consumer side using basic.cancel but I want to be able to this on rabbit server side.
Also I could kill all consumer connections from management plugin or delete whole queue and handle notification but that is also not good option for me.

Thanks for reading and maybe in future perhaps for implementing it

[kjnilsson]

What would you use this feature for?

[Solcloud Dev]

Mostly for similar purposes that linked posts mentions. But to summarize, here are some use cases I can think of right now:

1. I do not want to implement complex basic.cancel logic inside every consumer if that can be replaced by one central button (api call) per queue.
Currently we have complex system for managing number of running consumers per queue so we can (and currently do) just kill consumers
but of course depending on queue configuration (ack,requeu) and consumer side effects (killing before cleanup, inside transaction etc.) that is not always good solution.
We can handle SIGINT inside some consumers with basic.cancel but most consumers do hard long time side effects so we still eventually hit SIGKILL after some timeout.

2. Restarting consumers is expensive: (resource consuming, synchronizing, rebuilding cache, loading lots of data, etc.) but pausing queue will be one button click or one api call with no need to restart any consumer or implement complex client side basic.cancel logic.

3. Consumers update/maintenance: if I am deploying new consumer code I would like to be able to pause queue give some time until there is no unacked message, then spawn new consumers with new code and then when all consumers are up and ready (they take time to start) start consuming again. With this feature I will be able to automate this process.

4. Unexpected error: it is good to have one button to pause every consumer by pausing queue from central location, because consumers quickly rejecting every message because of some side conditions (network, api, disk, ...) cause network and cpu exhausting which in consequent can cause even more exhausting (logs,..) and more errors etc.

Dne pondělí 18. října 2021 v 13:35:21 UTC+2 uživatel kjnilsson napsal:

[Solcloud Dev]

Does these use cases sound reasonable for you?

Also can I ask how you or your customers handle when they need deploy new consumer code?

Do they create complete new queue and edit publishers and consumers to bind to new queue or they have something like this in their consumers:

if (this.msg.content.equals('pause-consumer')) {

    this.sendReject()

    this.basicCancel()

    sleep(999999)

}

or something else?

Thanks for reply

Dne úterý 19. října 2021 v 14:20:02 UTC+2 uživatel Solcloud Dev napsal:

[Bert Speckels]

I can only confirm that I miss this feature a lot too. We use RabbitMQ to process messages asynchronously in a cluster (Java/Spring backend) and occasionally need to pause processing of a queue. Mostly for maintenance purposes!

Currently we have to inform all cluster nodes in the cluster so that they stop all listeners on the queue. To continue processing, we must again inform all cluster nodes so that they start the listeners. We do that with Hazelcast to distribute the information in the cluster. This is very complex and error-prone: sometimes a cluster node doesn't realize it.

Naively, I imagine such a function in RabbitMQ to be very simple: A queue in the pause state simply does not have to pass any messages to the listener, as if there were no messages.

As far as I know ActiveMQ Artemis supports this at least via JMX and Management API:

https://activemq.apache.org/components/artemis/documentation/latest/management.html

"Pausing and resuming Queues: T

he QueueControl can pause and resume the underlying queue. When a queue is paused, it will receive messages but will not deliver them. When it's resumed, it'll begin delivering the queued messages, if any."

I expected that pausing an resuming queues is very essential for a queuing system. But I'm curious to hear why this isn't a good idea or difficult to implement.

With kind regards

Bert Speckels

[Karl Nilsson]

Pausing message delivery to consumers could be possible for quorum queues at least. It wouldn’t be possible to pause publishes however. 

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/f5a98679-9fdb-4a30-a360-daea5b810b81n%40googlegroups.com.

--

Karl Nilsson

[Bert Speckels]

Hey Karl

thanx for pushing me towards Quorum Queue: They seem to be perfect for our purpose! I didn't realize them since we started with RabbitMQ prior 2.8.

Do you mean that there is currently any possibility to pause those queue types?

Or is it just possible to implement such feature in the future?

With kind regards

Bert

To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/CAHC35TAiX2ERJ62PxVFr9UdP26%2BfNDV2JmLC8oxG3L-tFC-M5g%40mail.gmail.com.

[Karl Nilsson]

It is a possible future feature 

To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/CAFo4KCKxUxwyPbtJy7wW%2Bz-80-1a2HvWVhAcUPyaqjz_iXX4-w%40mail.gmail.com.

--

Karl Nilsson

[Solcloud Dev]

Honestly I also do not understand why it is so difficult to implement pausing message delivery to consumers, it sounds so simple, you already know how to deliver some messages so why is it so hard to just not delivering them when some switch is on, functional programming is different I guess

Dne sobota 17. září 2022 v 13:22:23 UTC+2 uživatel kjnilsson napsal:

[Michael Klishin]

All features are easy when you don't have to implement them yourself.

Please reconsider your tone: you very likely do not pay for RabbitMQ and not a contributor yet you feel privileged as hell to *demand* features.

"Not delivering messages when a switch is on" would not be any different in "functional programming". You'd have to consider a few other things

before you do so, which you conveniently left out in your "it's so damn easy" claim:

 * RabbitMQ core team is about 10 people, depending on how you count. There are hundreds of things customers and community want us to work on at any given time.

 * The delivery limiter mechanism was not built for a "switch" but for a number of outstanding messages which cannot be set to 0 per protocol violations

 * There are no specific proposals as to how the pausing would be communicated to the queue, whether there should be a timeout, how to expose this in metrics or management UI, and so on

But if you really need this feature and feel it would be so damn easy to implement, go ahead and submit a PR. It will be considered.