英文:
Removing queue before nack freezes my app
问题
我对RabbitMQ还不太熟悉，我想知道在我ack一个队列之前删除队列时，处理错误的最佳方法是什么。
if err := handle(); err != nil {
delivery.Nack(false, true)
} else {
delivery.Ack(false)
}
这段代码的问题在于我们的队列是基于一个与我们的调度器外部协调器相关的创建/删除的。所以当delivery被Nack并且队列被删除时，系统会挂起，因为它会不断尝试重新排队delivery。
为了解决这个问题，我可以检查delivery.Nack(false, true)是否返回错误，并在那里处理它。但是，如果Nack方法返回错误，最好的处理方式是什么？
注意：我正在使用https://github.com/streadway/amqp
英文:
I'm kind of new to rabbitmq and i was wondering what is the best way to handle an error I'm having when a delete a queue before I can ack a delivery on that queue.
if err := handle(); err != nil {
delivery.Nack(false, true)
} else {
delivery.Ack(false)
}
The problem with this code is that our queues are created/deleted based on a coordinator external to our dispatcher, so when delivery is Nack and the queue was deleted the system hangs because it keeps trying to requeue the delivery.
To solve the problem I can just check if the:
delivery.Nack(false, true)
returns an error and I can handle it there. But what would be the best approach to drop this delivery if the Nack method returned an error?
Note: I'm using https://github.com/streadway/amqp
答案1
得分: 2
这段代码的问题在于我们的队列是根据与调度程序外部的协调器的情况进行创建/删除的，这就是问题所在。我会质疑为什么你要这样做，而不是允许消费者定义所需的队列和绑定呢？
如果不能质疑/更改这一点，最好的选择可能是在deliver.Nack周围添加一个错误处理程序。但我认为这是一个由更大的设计问题引起的不愉快的解决方法。
英文:
> The problem with this code is that our queues are created/deleted based on a coordinator external to our dispatcher,
that is the problem, right there. i would question why you want to do this, instead of allowing the consumer to define the queue and binding that it needs?
barring the ability to question / change that, an error handler around the deliver.Nack is probably your best option. but i think that's an unpleasant workaround for a problem caused by larger design issue
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论