Запланированная повторная попытка связанного сообщения JMS - PullRequest
Новая
       26

Запланированная повторная попытка связанного сообщения JMS

1 голос
/ 24 сентября 2010

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

Существует сообщение A, и за ним следует соответствующее сообщение B со ссылкой.it.In Некоторые нечетные случаи, B прибывает перед A. Теперь в этом случае, должно быть 3 повторения после некоторых 'x' равных интервалов, чтобы видеть, прибыл ли A, и затем сохраняется ассоциация.

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

Можем ли мы использовать Quartz Job Scheduler для этой цели, чтобы избежать обработки проблем с многопоточностью и иметь PERSISTENT STORE для любого из следующих двух способов:

  1. Запланируйте задание в Кварце три раза и отслеживайте флаг в JobDataMap, чтобы проверить, успешны ли предыдущие попытки, затем вернитесь, ничего не делая

ИЛИ

2. Запланируйте задание на повторную попытку один раз, а затем, если повтор не удастся, запланируйте то же самое задание через несколько секунд.

Может ли кварц использоваться только для повторяющихся заданий и не иметь некоторого информационного диапазона о состоянии по заданию или есть какой-либо другой лучший способ сделать это.

1 Ответ

0 голосов
/ 27 января 2012

Вы должны сконфигурировать своего провайдера JMS, чтобы установить задержку доставки в вашей очереди сообщений.В вашем коде вы вызываете context.setRollbackOnly, чтобы прервать сообщение, которое не проходит проверку предварительных условий.

В этом случае сценарий выполнения кода становится следующим:

  • потребляет «B»,проверить наличие предварительных условий и обнаружить, что A не хватает
  • откатить транзакцию и сообщение вернется в очередь, оно будет повторно доставлено после того, как настроенная задержка
  • потребит и обработает следующее сообщение «A»
  • после задержки MDB потребляет и обрабатывает снова «B» с успехом
...