Rabbitmq-server: Nack messages that cannot be deposited to all queues due to max length reached
Under publisher confirms, messages are nacked when the broker could not process them. This issue requests to optionally treat "at least one queue is full" as one of the reasons when the broker could not process a message, instead of discarding old messages, which is the current behavior that may remain the default.
See also: https://groups.google.com/forum/#!topic/rabbitmq-users/Fzsdx1CEiWA
uvzubovs
All 10 comments
Similar in spirit to #499, should be evaluated together with it.
michaelklishin
on 12 Oct 2016
Just to make sure my understanding of the request is correct, the feature requested is to be able to configure a queue with a queue length limit to discard incoming messages (rather than from the head of the queue) and hook into the publisher confirm mechanism to nack when a routable queue is unable to accept a message due to the queue being "full"? Similarly to what may happen if the queue process crashes during processing.
kjnilsson
on 12 Oct 2016
You got it, Karl! Thank you very much for your insight.
uvzubovs
on 12 Oct 2016
It will make sence! Thumbs up!
peaksnail
on 18 Oct 2016
Seconded. The message-discarding behavior has been universally unexpected among people I've talked with about it, and it would make sense to add this as an (at least optional) feature.
jrlog
on 18 Oct 2016
Yes, please! I have systems that are far more complicated than they need to be because of the default behavior. This one feature would would be a godsend for me. Keep the default, but make it an option.
hsquirrel
on 28 Oct 2016
I too would love to see this feature
smnirven
on 2 Aug 2017
+1
chadrik
on 2 Sep 2017
How does this look to a JMS publisher? Would it get an easy-to-handle exception?
ben-spiller
on 13 Feb 2018
@ben-spiller - I chatted with @acogoluegnes to see what would happen in this scenario and the scenario where I commented here. It turns out that the RabbitMQ JMS client does not use publisher confirms so it would not know whether or not a published message was rejected.
As I'm sure you know, JMS specifies an API but not an implementation, and this would be a change to our implementation. If you would like to submit a pull request with this feature here, it would be appreciated. Thanks.
lukebakken
on 13 Feb 2018
Related issues
Docjones
路
5Comments
firewave
路
8Comments
michaelklishin
路
6Comments
ppyoosuf
路
5Comments
cenekzach
路
5Comments
Most helpful comment
Just to make sure my understanding of the request is correct, the feature requested is to be able to configure a queue with a queue length limit to discard incoming messages (rather than from the head of the queue) and hook into the publisher confirm mechanism to
nackwhen a routable queue is unable to accept a message due to the queue being "full"? Similarly to what may happen if the queue process crashes during processing.