Nack messages that cannot be deposited to all queues due to max length reached #995
Comments
uvzubovs
changed the title
|
Similar in spirit to #499, should be evaluated together with it. |
|
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 |
|
You got it, Karl! Thank you very much for your insight. |
|
It will make sence! Thumbs up! |
|
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. |
|
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. |
|
I too would love to see this feature |
|
+1 |
If a queue is to be overflowed by a delivery it can reject the delivery or drop messages from the head. To reject delivery overflow can be configured to `reject_publish`, to drop head it's `drop_head` (default setting). Messages which will be rejected should still confirm being routed, so mandatory expectations are not accumulated on the channel side. Slave nodes will only confirm if a message was published or discarded. To drop confirms from slaves, all confirms for a message are cleared when the message is rejected. When promoting a new master, left-behind deliveries should be rejected if the queue is full, just like normal deliveries. Fixes #995 [#151294447]
If a queue is to be overflowed by a delivery it can reject the delivery or drop messages from the head. To reject delivery overflow can be configured to `reject_publish`, to drop head it's `drop_head` (default setting). Messages which will be rejected should still confirm being routed, so mandatory expectations are not accumulated on the channel side. Slave nodes will only confirm if a message was published or discarded. To drop confirms from slaves, all confirms for a message are cleared when the message is rejected. When promoting a new master, left-behind deliveries should be rejected if the queue is full, just like normal deliveries. Fixes #995 [#151294447]
|
How does this look to a JMS publisher? Would it get an easy-to-handle exception? |
|
@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. |
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
The text was updated successfully, but these errors were encountered: