ReQueue amqp message without retry strategy.

Description
Hello, recently I am implementing messenger amqp transport for my queues which are handling my "event bus" messages. So my amqp setup is fanout type exchange and X queues binded.

Now if message on ONE consumer failed, retry strategy put back on queues BUT unfortunately using my exchange so this retry strategy will make doubles on other queues.

My solution here is to make it configurable. Set option requeue: true under some transport configuration, which will take action in https://github.com/symfony/amqp-messenger/blob/master/Transport/AmqpReceiver.php#L123 and set AMQP_REQUEUE option instead AMQP_NOPARAM, and will disable this middleware https://github.com/symfony/messenger/blob/master/Middleware/RejectRedeliveredMessageMiddleware.php because if we requeue our message this middleware will throw exception.

I think when we are aware of this behavior - that this will be one point of failure and our queue will stop consuming - it should be configurable. I was talking about this on slack https://symfony-devs.slack.com/archives/C9PQ75TV3/p1596565569301600

What you thinking about this solution, maybe is something already implemented.. But I don't think so.. Let me know I would make PR with this, but I need some feedback :)

Asked Dec 14 '21 06:12
avatar bzajacc
bzajacc

2 Answer:

In my company the default behavior is actually block the queue and not use a deadletter queue to not affect the order. I'm doing this not with Messenger but I think it can be interesting to have something like that using AMQP.

Because with the retry mechanism you move the message to another queue for X seconds.

This is great for projections (with 1 consumer) where order is very important.

1
Answered Aug 11 '20 at 19:46
avatar  of monteiro
monteiro

@Tobion I don't think so, because that issue is handling delayed messages. My is to stop queue and wait to support to check what is wrong.

If we will delay the message, we lose order, or ( correct me if i am wrong ) if we set delay to 0 - message will instantly go back to origin queue without start consuming next one, and put this message at the start of queue list? (like requeue behavior) I don't think so..

Even if I'm wrong this solution is workaround to requeue in my case. Another (in my opinion) bad behavior is that in his solution we will have unnecessary new temp queue (if delay 0 is working like above).

1
Answered Aug 15 '20 at 19:45
avatar  of bzajacc
bzajacc