Не существует прямого JMS API для повторной отправки сообщения из DLQ в его исходную очередь. На самом деле API JMS даже не обсуждает очереди недоставленных сообщений. Это просто соглашение, используемое большинством брокеров для работы с сообщениями, которые не могут быть использованы.
Вам необходимо создать фактического потребителя JMS для получения сообщения из DLQ, а затем создать производителя JMS для отправки. сообщение возвращается в исходную очередь.
Важно использовать режим Session.TRANSACTED
, чтобы избежать потенциальной потери или дублирования сообщения.
Если вы используете Session.AUTO_ACKNOWLEDGE
и существует проблема между временем приема и отправки сообщения (например, сбой приложения, сбой оборудования и т. Д. c.), То сообщение может быть потеряно из-за факт, что это было уже подтверждено прежде, чем это было успешно отправлено.
Если вы используете Session.CLIENT_ACKNOWLEDGE
и существует проблема между временем отправки и подтверждения сообщения, то в конечном итоге сообщение может быть дублировано из-за того, что оно уже было отправлено до того, как оно было успешно подтверждено.
Обе операции должны быть частью транзакции JMS, чтобы работа была атомарной c.
Наконец, я рекомендую вам либо вызвать commit()
для транзакции сеанс для каждого отправленного сообщения или после небольшой партии сообщений (например, 10). Учитывая, что вы не знаете, сколько сообщений в DLQ, было бы неразумно обрабатывать каждое сообщение в одной транзакции. Как правило, вы хотите, чтобы транзакция была как можно меньше, чтобы минимизировать окно, во время которого может произойти ошибка, и работу транзакции необходимо будет выполнить снова. Кроме того, чем больше транзакция, тем больше памяти кучи потребуется брокеру для отслеживания работы в транзакции. Помните, что вы можете вызывать commit()
в одном сеансе столько раз, сколько захотите. Вам не нужно создавать новый сеанс для каждой транзакции.