Как можно надежно отправить сообщение JMS? (сбой при ошибках MessageProducer.send())

Question

Возможно ли надежно отправить сообщение JMS адресату? Надежно я имею в виду обеспечение того, что, если, например, MessageProducer.send() вызов по какой-то причине невозможен, он будет повторно выполнен автоматически. Я понимаю, что сеанс транзакции может использовать .recover() в качестве последнего средства, но как насчет повторной попытки? Например. У меня прерывистый сетевой сбой между сеансами был установлен и попытался отправить сообщение. Как будет recover() помощь в этом случае?

Answer 1

Насколько я знаю, JMS не поддерживает такое поведение. Вы можете искать среди определенных расширений поставщиков, но, IMHO, маловероятно, что вы найдете что-то подходящее для ваших нужд.

Я вижу только два решения вашей проблемы:

1. Реализовать его. Вы можете управлять сеансом JMS вручную, улавливать любое исключение и, если необходимо, использовать функцию «только откат» диспетчера транзакций, чтобы аннулировать транзакцию.

2. Используйте локальную очередь для хранения сообщений и используйте фоновый сервис, чтобы переместить их в целевую удаленную очередь. Обратите внимание, что многие администраторы очереди поддерживают это, например. Store and forward Queues of ActiveMQ. Очевидно, что в этом случае граница транзакции не будет включать удаленную очередь.

Я знаю, что 2-е решения не являются полным ответом на вашу проблему, но много раз это достаточно.

Answer 2

В JMS не указано поведение, которое вы ищите. На самом деле JMS специально решает проблемы из-за сбоя сети, отмечая, что вы можете получить одно и то же сообщение дважды и называет это «функционально дублирующимся» сообщением, поскольку с точки зрения брокера JMS он был доставлен только один раз.

Поскольку это не является частью JMS, ваш ответ лежит на разных вариантах реализации поставщика. Например, WebSphere MQ имеет функцию «Диспетчер очередей нескольких экземпляров» с версии 7.0.1. Клиентское приложение v7.0.1 автоматически повторит соединение и даже выполнит QMgr от первичного до вторичного узла в случае сбоя. Приложение блокирует, пока это происходит, и не знает об откате.

Однако, даже при таком поведении ваше приложение по-прежнему нуждается в коде для отказа. Например, если вы используете автоматическое повторное подключение WMQ (или переадресацию какого-либо другого провайдера), вы, вероятно, захотите настроить время, в течение которого приложение может заблокировать ожидание восстановления соединения, чтобы пользователь не испытывал неопределенное зависание. Когда вызов разблокируется, транзакция откатывается, и в коде должна повторяться любая повторная попытка. Это необходимо, поскольку транзакция связана с соединением, которое больше не действует.