Возврат из очереди неупорядочен в ActiveMQ Artemis 2.11.0 - PullRequest
Новая
       5

Возврат из очереди неупорядочен в ActiveMQ Artemis 2.11.0

0 голосов
/ 20 февраля 2020

Если ActiveMQ Artemis настроен на redelivery-delay> 0 и JMS-прослушиватель использует ctx.rollback() или ctx.recover(), то брокер повторно доставит сообщение, как и ожидалось. Но если производитель отправляет сообщение в очередь во время повторной доставки, то получатель получает неупорядоченные сообщения.

Например:

Очередь: 1 -> сообщение 1 доставлено, как и ожидалось

Pu sh во время фазы доставки

Очередь: 2, 3 -> получатель получает 2,3,1

С redelivery-delay из 0 все в порядке, но частота повторных поставок на стороне потребителя слишком высока. Я ожидаю, что каждая доставка потребителю должна быть остановлена ​​до тех пор, пока неподтвержденное сообщение не будет удалено из очереди или подтверждено. Мы используем очередь для связи с отдельными устройствами. Каждое устройство имеет свою очередь ввода-вывода с одним потребителем. Слово очередь подсказывает мне строгий порядок. Было бы неплохо сделать это поведение настраиваемым, например "strict_redelivery_order".

1 Ответ

0 голосов
/ 02 мая 2020

То, что вы видите, - это ожидаемое поведение. Если вы используете redelivery-delay> 0, то заказ на доставку будет прерван. Если вы используете redelivery-delay из 0, то заказ на доставку не будет нарушен. Поэтому, если вы хотите поддерживать строгий порядок, используйте redelivery-delay из 0.

Если посредник заблокировал доставку всех других сообщений в очередь во время задержки повторной доставки, которая полностью повредит производительности пропускной способности сообщения. Что если задержка повторной доставки составила 60 секунд или 10 минут? Очередь будет заблокирована все это время. Это не подходит для корпоративного брокера сообщений, обслуживающего сотни или, возможно, тысячи клиентов, каждый из которых может регулярно инициировать доставку в общих очередях. Это поведение не настраивается.

Если вам абсолютно необходимо поддерживать порядок сообщений даже для сообщений, которые не могут быть немедленно использованы, и redelivery-delay из 0 вызывает слишком быстрые повторные доставки, тогда я вижу несколько возможных вариантов ( без определенного порядка):

  • Настройте адрес недоставленной буквы и установите max-delivery-attempts на подходящее значение, чтобы после нескольких повторных доставок сообщение о проблемах c могло быть очищено из очереди.
  • Реализуйте собственную задержку в своем клиенте. Это может быть так же просто, как перехват любого исключения и использование Thread.sleep() перед вызовом ctx.rollback().
...