Удаление сообщения, которое повторно отправлено

Question

У меня есть брокер ActiveMQ и один потребитель. Потребитель получает сообщение о том, что он не может обработать, потому что служба, в которой он работает, имеет ошибку (после исправления она будет прекрасной). Таким образом, сообщение постоянно обновляется (возврат покупателей) - мы используем сеансы JMS. С нашей текущей конфигурацией он будет постоянно обновлять его каждые 10 минут в течение 1 дня. Это, очевидно, вызывает проблему, потому что другие сообщения не потребляются.

Чтобы решить эту проблему, я получил доступ к очереди через JMX и попытался удалить это сообщение, но его там нет. Я предполагаю, что он кэшируется на потребителя и не отображается у брокера. Есть ли способ удалить это сообщение, кроме перезапуска приложения?

Возможно ли настроить механизм повторной доставки, чтобы в конце очереди было отправлено такое сообщение (которое вызывает блокировку в реальном времени), чтобы можно было обрабатывать другие сообщения?

10 минут на 1 день политики переоформления должны оставаться как есть.

Answer 1

Установка jms.nonBlockingRedelivery = true на фабрике подключений устранена проблема. Теперь, даже если есть сообщение redelivered, оно не блокирует обработку других сообщений.

Answer 2

Единственный способ получить его на обратной стороне очереди - воспроизвести его в очереди. Политики переадресации можно настроить только до места назначения на фабрике соединений.

Учитывая, что у вас уже есть соединение, не должно быть сложно создать производителя, который может либо переместить данное сообщение в DLQ, либо вернуть его в очередь, когда вы столкнетесь с этой конкретной ошибкой.

Answer 3

Я думаю, вы правы, что сообщения застревают в буфере предварительной выборки потребителя, и я не знаю, как их удалить.

Я бы изменил политику повторной доставки для отправки в DLQ после второго сбоя с гораздо более коротким интервалом между ними, например 30 секунд, и я бы сконфигурировал стратегию DLQ как , поэтому вы получаете отдельный DLQ содержащие только сообщения из этой очереди. Затем настройте потребителя на этом DLQ, чтобы переместить сообщения в конец главной очереди всякий раз, когда выполняется условие обработки (будь то после определенной задержки или на основе чтения некоторого значения флага из базы данных или что-то еще). Этот потребитель должен использовать логику «каждые 10 минут в течение 1 дня», а не в политике переподготовки, где у вас ее есть.

Это приведет к тому, что мусорные батареи будут выведены из основной очереди, чтобы они не задерживали другие сообщения от потребления, но при этом гарантируют, что они будут повторно обработаны позже. И он помещает их в брокер, а не в буфер предварительной выборки потребителя, где вы можете их просматривать и удалять.