Я планировал отложить обработку сообщений в очереди, следуя этим двум ссылкам: link1link2. Итак, как было предложено в ссылке. Я объявил исходную очередь с аргументами x-dead-letter-exchange и x-dead-letter-routing-key. Который опубликовал сообщения так называемому dead-letter-queue, когда сообщение либо не получило обработки потребителем, либо ttl, либо длина очереди превысила. Теперь в dead-letter-queue аналогичные аргументы были установлены вместе с параметром ttl. Предположим, что переиздание сообщений в исходную очередь после ttl превышает. Но проблема в том, что это удаление всех сообщений.Мертвые письма, не получающие запрос в исходную очередь после ttl
Кроме того, здесь есть улов. Если я явно публикую неудавшиеся сообщения из исходной очереди в dead-letter-queue. Затем после ttl он переиздает сообщения в исходную очередь. Почему это так и как я могу заставить его работать. Так что очередь мертвых букв переиздает сообщения в исходную очередь, а не отбрасывает. Я использую RabbitMQ 3.0.0.
FYI, я создал как обмены direct типа наряду с маршрутизацией ключа
Вместо того, чтобы делать то, что вы предложили. Мы могли бы также публично опубликовать сообщение об ошибке из исходной очереди в «мертвую букву» вместо того, чтобы использовать «х-мертвую букву» и «х-мертвую букву-маршрутизацию-ключ». Затем также очередь мертвых букв переиздает сообщения в исходную очередь после ttl. Таким образом, я не могу понять, в чем разница в публикации сообщения явно и с помощью встроенных функций. – Naresh
способ, которым вы описываете, будет работать только в том случае, если у вас есть одна очередь. В моей ссылке этот метод работает для того, чтобы иметь N количество очередей, которые мертвая буква в одну очередь повторов. – jhilden
В любом случае, но почему существует разница в публикации сообщения явно и с помощью встроенных функций. Любые идеи – Naresh