Логика постановки задачи на неудачу сельдерея (RabbitMQ) - PullRequest
Новая
       11

Логика постановки задачи на неудачу сельдерея (RabbitMQ)

0 голосов
/ 05 марта 2019

У меня есть следующие настройки: 

celery version = 4.2.1
task_reject_on_worker_lost = True
task_acks_late = True

Я пытаюсь сначала получить сообщение для маршрутизации в «QueueA», и если работник сельдерея, который его обрабатывает, внезапно завершается с ошибкой, я бы хотел, чтобы сообщение было повторно отправлено.-очереди в новую очередь "QueueB".Возможно ли это сделать с помощью настроек моей очереди RabbitMQ или с помощью сельдерея?

У меня уже есть обмен недоставленными письмами, правильно настроенный для QueueA, который обрабатывает этот тип маршрутизации, например, с TTL (т.е. сообщение отправляетсяв очередь A сидит до тех пор, пока TTL не перейдет в очередь недоставленных сообщений и в конечном итоге вернется в очередь B).

1 Ответ

0 голосов
/ 19 марта 2019

Из списка рассылки RabbitMQ

Автоматическое повторное запрос на закрытие канала (и, конечно же, соединения) всегда происходит с одной и той же очередью 1 . Такой сценарий не приводит к незаполненным буквам, любые настройки DLX не будут иметь никакого эффекта. При наличии очередей кворума в 3.8 автоматическое повторное заполнение может иногда приводить к неправильным буквам, поскольку есть предел количества повторных поставок. Это было бы близко к тому, что вы ищете. Поскольку очереди кворума не доступны в RabbitMQ 3.7, они также не доступны. 3.8.0 находится на бета-версии 3 в настоящее время [2] и выйдет в середине 2019 года. 1. https://www.rabbitmq.com/confirms.html 2. https://github.com/rabbitmq/rabbitmq-server/releases/tag/v3.8.0-beta.3 Лимит повторной доставки задокументирован здесь (https://next.rabbitmq.com/quorum-queues.html)

...