Многопоточное JMS-приложение

Question

Я работаю над многопоточным кодом приемника и издателя JMS. XML-сообщение получено из очереди, вызываются хранимые процедуры (70 секунд), а ответ отправляется в раздел в течение 90 секунд Мне нужно справиться с условием, когда брокер не работает. то есть состояние, при котором сообщения принимаются из очереди и обрабатываются в java, в то время как очередь и тема будут недоступны. Тогда как обрабатывать те сообщения, которые не находятся в очереди и не отправляются в тему, но находятся в памяти Java? Доступны различные варианты:

1.Чтобы использовать CLIENT_ACKNOWLEDGE 2. Отделить код издателя от кода получателя. 3.Иметь утилиту ошибок, которая будет принимать сообщения из журнала, обрабатывать их и отправлять в раздел (наименее предпочтительный)

Пожалуйста, предложите мне правильный вариант

Answer 1

Использовать транзакционный сеанс. Поглотите сообщение и отправьте ответ в рамках одной единицы работы и явно отправьте COMMIT после отправки ответа. Затем, если брокер умрет, пока транзакция не завершена, входное сообщение будет откатано. Если вы включите обновление БД в двухфазную скоординированную транзакцию, то оно также может быть отменено, если брокер отключится. Для этого требуется, чтобы получатель и ответчик были в одном потоке, поскольку JMS ограничивает сеансы для каждого потока, но вы можете иметь несколько потоков, работающих параллельно.

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

Answer 2

Одним из решений является использование дБ для промежуточной хранимой процедуры.Таким образом, шаги будут такими:

1. Consume Message from Queue and store into db and use Client_Acknowledge.
2. Run stored procedures on the consumed message.
3. Once the procedure is over, send message from db to the topic.
4. Delete message once acknowledgement is recieved.

Если между темой и очередью встанет очередь, вам просто нужно отправить сообщение снова, когда подтверждение не получено из темы.

Ну, я не уверенявляется ли это лучшей альтернативой и хотите посмотреть, как сообщество ответит на этот вопрос.