Poison Message Handling for Classic Queues

[SimoneGiusso]

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

A message is causing the consumer to fail critically (e.g. OOM).

Currently, "[if a consumer dies (its channel is closed, connection is closed, or TCP connection is lost) without sending an ack, RabbitMQ will understand that a message wasn't processed fully and will re-queue it. If there are other consumers online at the same time, it will then quickly redeliver it to another consumer.](https://www.rabbitmq.com/tutorials/tutorial-two-java.html#:~:text=If%20a%20consumer%20dies%20(its,redeliver%20it%20to%20another%20consumer.)"

In this way the message will be retried indefinitely.

Describe the solution you'd like

I'd like have the Poison Message Handling for Quorum Queues for classic queue as well. On of the reason is that I'm using the priority policy available for classic queue which is unavailable from quorum queue.

Describe alternatives you've considered

I think the only available solution is to associate a counter to the specific message and store it on an external system (e.g. DB) before processing the message. When the message will be redelivered and re-consumed by the consumer that will be back to live, it checks the counter. If the counter exceed a threshold, skip it.

Additional context

I'm not sure this is the right repository. In case it is not, I'll be happy to open the issue elsewhere.

[lukebakken]

Thanks for using RabbitMQ.

Before filing a new issue for any software project, it's best to see if your request has been discussed before:

https://github.com/rabbitmq/rabbitmq-server/issues?q=is%3Aissue+poison

In your case, the following apply:

• Redelivery counts in classic queues #2013
• Poison Message Handling in Classic Queues #2654
• [Possible feature] Prevent consume message NACK loops (DoS) #1020
• Redelivery count for messages #502

[mkuratczyk]

Worth mentioning that we have a prototype for priority feature in quorum queues. It's quite a bit different than the classic queue implementation but it'd be great if you could provide feedback whether that meets your needs:
#10041
A build with this feature is mentioned in the PR and also available as a docker image:
pivotalrabbitmq/rabbitmq:qq-priorities-prototype-otp-max-bazel

Note that the priority values work differently - there are only 3 priorities and the value provided in the message maps as follows:
P < 4 - low
P = 4 - normal
P > 4 - high