Как остановить обработку сообщений перед их развертыванием? - PullRequest
2 голосов
/ 26 апреля 2011

Дано:

  • Очередь сообщений JMS.
  • Служба таймера, которая периодически помещает сообщения в эту очередь (из базы данных).
  • Управляемый сообщениями компонент JEE6, который читает из очереди.
  • Служба таймера и управляемый сообщениями компонент являются частью различных модулей развертывания.

Проблема:

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

Есть ли способ автоматизировать такое поведение?Или можно предотвратить отмену развертывания, если служба таймера все еще работает?В настоящее время мы используем JBoss 4.2.3.

Non-Solutions:

  • Рефакторинг единиц развертывания, поскольку в нем участвуют несколько отделов.
  • Я знаю, что сбой системы не будет покрыт и что пуленепробиваемое решение должно включать стратегию восстановления.

1 Ответ

2 голосов
/ 28 апреля 2011

Каждый развернутый MDB имеет интерфейс управления JMX MBean.ObjectName этого MBean варьируется в зависимости от развертывания (и может также отличаться в разных версиях JBoss).Я использую JBoss 4.3, и формат ObjectName:

Domain Name:    jboss.j2ee
service:    EJB3
name:   <MDB Name>
ear:    <EAR Name>  (if applicable)
jar:    <JAR Name>

Если ваша служба таймера является JBoss ServiceMBean, вы можете сделать свой MDB зависимым от таймераиспользуя аннотацию JBoss @ Depends («имя объекта службы таймера») .Это заставит службу таймера запускаться до запуска MDB (поэтому желательно, чтобы служба таймера имела некоторую задержку после запуска), но что более важно, я полагаю обратное произойдет при отмене развертывания, и служба таймера должна остановитьсяСначала МДБ.

Если это работает, он заботится о порядке, но я не думаю, что вы можете заставить MDB не отменять развертывание во время работы таймера.Подробная информация о вашем приложении может не поддерживать это, но один из способов решения этой проблемы - использовать JBoss Quartz JCA адаптер притока , который по существу свяжет таймер и процессор сообщений в один (это как MDB, но он получает события таймера, а не сообщения), избавляя вас от необходимости бороться с зависимостями между двумя компонентами.

=============================== Попытка № 2 ================================

Хорошо, значит, вы хотите предотвратить останов MDB, когда очередь подачи имеет глубину больше нуля.Этот подход должен работать для вас, хотя он очень специфичен для JBoss.

  1. Реализация JMX NotificationListener , который прослушивает изменения состояния MDe Delegate MBean.
  2. Вы также можете реализовать JMX NotificationFilter , чтобы сузить конкретные события, которые вы хотите прослушивать.
  3. Требуемое изменение состояния находится в атрибуте Состояние и требуемый переход: 3 -> 1 ( Запущено -> Остановка )
  4. Уведомления JMX в [этой версии] JBoss выдаются синхронно и будут блокироваться до тех пор, пока слушатель уведомлений не вернется.Когда ваш слушатель получит это уведомление, запустите цикл опроса в очереди подачи MDB MBean (не спрашивал, используете ли вы JBoss Messaging, но я предполагаю, что вы есть).Пока MessageCount равен> 0, вы продолжаете опрос.Когда счетчик сообщений в очереди равен нулю, слушатель возвращается и MDB останавливается.
  5. Убедитесь, что в ваш цикл опроса добавлен краткий сон, а также время ожидания опроса (на случай, если что-то не получится).
  6. Вы также можете не возвращаться до тех пор, пока число сообщений не станет равным 0, по крайней мере, для n циклов опроса в случае, если при передаче имеется некоторое незафиксированное сообщение, которое может не отображаться в числе сообщений.

Суть в том, что во время вызова слушателя изменения атрибута сообщение будет продолжать обрабатываться.Когда прослушиватель изменения атрибута вернется, остановка MDB продолжится.

Если ваша реализация JMS является локальной системой обмена сообщениями JBoss в VM, счетчик сообщений очереди будет доступен в MBean управления очередью.Для любой другой настройки вам может потребоваться выполнить собственный вызов API JMS, чтобы узнать количество сообщений в очереди, или, используя более грубый метод, вы можете просто запросить JMS QueueBrowser и подсчитать количество сообщений..

...