Применение обработчика очереди зависших сообщений в WebSphere MQ

Websphere MQ содержит утилиту для обработки недоставленных сообщений Dead Letter Queue (DLQ) Handler, которую можно реализовать как объект серверной службы или запускать при появлении сообщений в очереди зависших сообщений (DLQ). В этой статье рассказывается, как реализовать упомянутую утилиту обоими способами для упрощения управления сообщениями с помощью WebSphere MQ.

Варун Гупта, сотрудник технической службы WebSphere MQ, IBM

Photo of Varun GuptaВарун Гупта — сотрудник технической службы WebSphere MQ в индийском филиале IBM. Имеет степень магистра прикладной математики и пять лет опыта работы в сфере информационных технологий с такими продуктами для обработки сообщений, как WebSphere Message Broker и WebSphere MQ. Является сертифицированным администратором IBM WebSphere MQ и оказывает услуги по администрированию продуктов WebSphere Message Broker и WebSphere MQ клиентам в США. Связаться с Варуном можно по адресу vagupta7@in.ibm.com.



29.08.2012

Введение

IBM® WebSphere® MQ представляет собой ПО промежуточного уровня корпорации IBM, ориентированное на передачу сообщений. Он обеспечивает взаимодействие независимых и потенциально непараллельных приложений в разнородной системе и поддерживает более 80 разных платформ.

Одной из сильных сторон WebSphere MQ является его способность надежно доставлять сообщения в очередь назначения. Конечно, время от времени возникают сетевые или конфигурационные проблемы, которые приводят к тому, что сообщения не достигают очереди назначения. В этом случае они помещаются в очередь зависших сообщений (DLQ) вместе с сообщениями, возвращенными из очереди назначения. Эта статья посвящена очереди DLQ и утилите DLQ Handler, которая обрабатывает сообщения, помещенные в DLQ.

Утилиту DLQ Handler можно настроить так, чтобы она работала как объект серверной службы. Ее также можно запускать на основе определенных в DLQ критериев. В данной статье описывается, как реализовать оба упомянутых сценария, и поясняются достоинства и недостатки каждого из них. Сообщения могут помещаться в DLQ локально, удаленно или через быстрые каналы. В этой статье используется сценарий удаленного размещения сообщений.

Сценарий 1: настройка DLQ в качестве объекта серверной службы

Если принимающий канал не может поместить сообщения в очередь назначения, то эти сообщения помещаются в DLQ удаленного менеджера очереди WebSphere MQ при условии, что имеется очередь DLQ, определенная для этой задачи. Утилита DLQ Handler ждет появления сообщений в DLQ. Очередь DLQ, используемую для приема недоставленных сообщений, можно определить через пункт меню менеджера очереди Properties => Default dead queue(Свойства => Стандартная очередь зависших сообщений). Например, на рисунке 1 в качестве DLQ для сообщений, не доставленных в менеджер очереди IBMQMR, указана очередь DEADQ:

Рисунок 1. Имя DLQ для менеджера очереди
Name DLQ of queue manager

Чтобы запустить обработчик DLQ как службу, нужно определить объект серверной службы в этом менеджере очереди. В данном примере для этого используется пакетный файл и таблица правил для DLQ Handler. Содержимое исполняемого пакетного файла dlqhandler.bat показано в листинге 1. В файл runmqdlq передаются четыре разделенных пробелами аргумента, как показано в поле STARTARG объекта серверной службы с именем dlqhandler в листинге 3.

Листинг 1. Содержимое файла dlqhandler.bat
cd "C:\Program Files\IBM\WebSphere MQ\bin"
runmqdlq %1 %2 %3 %4

Таблица правил определяется с помощью последовательных функций REASON и ACTION и функции WAIT (YES), которая означает, что утилита DLQ Handler ждет появления сообщений в очереди DLQ в течение неопределенно длительного времени, как показано в листинге 2. В результате, как только недоставленное сообщение попадает в очередь DLQ, оно обрабатывается утилитой DLQ Handler в соответствии с таблицей правил и пересылается во вторичную очередь DLQ, например, DLQX в менеджере очереди IBMQMR. В этом первом сценарии утилита DLQ Handler работает как объект серверной службы менеджера очереди IBMQMR.

Листинг 2. Содержимое таблицы правил RULETBL.RUL
INPUTQ('DEADQ') INPUTQM('IBMQMR') RETRYINT(45) WAIT(YES)
REASON(MQRC_Q_FULL) ACTION(FWD) FWDQ(DLQX) FWDQM(IBMQMR)

Согласно приведенному ниже листингу 3, в режиме runmqsc вы указываете объект службы и передаете значения параметрам, такие как команда запуска (STARTCMD), начальный аргумент (STARTARG) и файлы стандартного вывода и журнала ошибок (STDOUT и STDERR). В целях тестирования переменной CONTROL (управление) присвоено значение MANUAL (ручное). Абсолютный путь файлов может быть любым и зависит от конфигурации вашей файловой системы.

Листинг 3. Определение объекта серверной службы для утилиты DLQ Handler
DEFINE SERVICE(dlqhandler) +
SERVTYPE(SERVER) +
CONTROL(MANUAL) +
STARTCMD('C:\IBM\WebSphere\MQ\dlqhandler.bat') +
DESCR('обработчик очереди зависших сообщений, как серверная служба') +
STARTARG('DEADQ IBMQMR < C:\IBM\WebSphere\MQ\RULETBL.RUL') +
STDOUT('C:\IBM\WebSphere\MQ\Log.txt') +
STDERR('C:\IBM\WebSphere\MQ\Err.txt') +
REPLACE

В зависимости от требований вы можете присвоить переменной CONTROL (управление) значение MANUAL (ручное), QUEUE MANAGER (менеджер очереди) или STARTONLY (только запуск). Значение STARTCMD представляет собой абсолютный путь к исполняемому файлу dlqhandler.bat (в Windows), как показано выше в листинге 3. После определения объекта серверной службы для утилиты DLQ Handler нужно убедиться в том, что идентификатор группы mqm и идентификатор пользователя MUSR_MQADMIN (в Windows) имеют разрешения на чтение и исполнение файла dlqhandler.bat. RULETBL.RUL представляет собой файл таблицы правил.

Попробуйте запустить объект серверной службы, контролируя файлы журнала ошибок менеджера очереди IBMQMR и файлы стандартного вывода и журнала ошибок, которые вы указали в STDOUT и STDERR для этого объекта серверной службы DLQ Handler. В листинге 4 показано состояние объекта серверной службы, полученное с помощью команды MQSC:

Листинг 4. Отображение состояния объекта серверной службы
display svstatus('dlqhandler')
1 : display svstatus('dlqhandler')
AMQ8632: Display service status details.
     SERVICE(dlqhandler)                     STATUS(RUNNING)
     PID(3396)                               SERVTYPE(SERVER)
     STARTDA(2011-11-22)                     STARTTI(20.54.28)
     CONTROL(MANUAL)
     STARTCMD(C:\IBM\WebSphere\MQ\dlqhandler.bat)
     STARTARG(DEADQ IBMQMR < C:\IBM\WebSphere\MQ\RULETBL.RUL)
     STOPCMD( )                              STOPARG( )
     DESCR(обработчик очереди зависших сообщений, как серверная служба)
     STDOUT(C:\IBM\WebSphere\MQ\Log.txt)
     STDERR(C:\IBM\WebSphere\MQ\Err.txt)

После запуска объекта серверной службы для DLQ Handler вы увидите запись о его запуске в журнале ошибок менеджера очереди:

Рисунок 2. Журнал ошибок менеджера очереди сообщает о запуске DLQ Handler
Queue manager error log says DLQ Handler started

Кроме того, с помощью программы WebSphere MQ Explorer можно увидеть, что IPPROC=1 в DLQ, как показано ниже на рисунке 3, если установить указатель runmqdlq на DLQ. Можно также проверить состояние DLQ с помощью команды MQSC.

Рисунок 3. Состояние DLQ и его открытый входной счетчик
DLQ status and its open input count

Протестируйте Сценарий 1, поместив сообщения в очередь DLQ с помощью функции удаленного занесения менеджера очереди IBMQMR. Эти сообщения будут обработаны утилитой DLQ Handler, которая работает как объект серверной службы dlqhandler. Файл таблицы правил RULETBL.RUL передается в DLQ Handler в качестве аргумента и обеспечивает обработку недоставленных сообщений в соответствии с содержащимися в нем парами причина/действие. Если DLQ Handler работает как объект серверной службы, он все время использует ресурсы ЦП сервера, а это значит, что он постоянно следит за DLQ и готов обработать все недоставленные сообщения в соответствии с таблицей правил.

Недостаток реализации DLQ Handler в виде объекта серверной службы заключается в том, что если вы попытаетесь остановить эту службу в Windows, она заявит, что вы не указали команду остановки STOPCMD в определении объекта серверной службы, поскольку в конце DLQ Handler как объекта серверной службы отсутствуют аргументы команды остановки. Вы увидите эту проблему, если определите объект серверной службы DLQ Handler, присвоив переменной CONTROL значение QUEUE MANAGER, — другими словами, серверная служба запускается и останавливается только одновременно с запуском и остановкой соответствующего менеджера очереди.

Сценарий 2: Запуск утилиты DLQ Handler

В Сценарии 2 функция запуска WebSphere MQ настроена таким образом, чтобы утилита DLQ Handler запускалась и обрабатывала недоставленные сообщения только при поступлении их в очередь DLQ. Для настройки Сценария 2 определите объект процесса processdlq внутри менеджера очереди IBMQMR, который запускается при каждом удовлетворении условий запуска. Чтобы избежать непредвиденных результатов в DLQ с сообщением MQFB_APPL_CANNOT_BE_STARTED (не удается запустить приложение), укажите в поле Application ID абсолютный путь к программе или процессу, который надо запустить.

Листинг 5. Менеджер очереди обрабатывает определение объекта
display process('processdlq') all
1 : display process('processdlq') all
AMQ8407: Display Process details.
    PROCESS(processdlq)                     APPLTYPE(WINDOWSNT)
    APPLICID(C:\IBM\WebSphere\MQ\dlq_trigger.bat)
    ENVRDATA( )                             USERDATA( )
    DESCR( )                                ALTDATE(2011-11-16)
    ALTTIME(00.43.41)

Объект процесса processdlq имеет поле Application ID APPLICID и исполняемый файл dlq_trigger.bat. В листинге 6 показано содержимое файла dlq_trigger.bat, который используется для передачи правил утилите DLQ Handler:

Листинг 6. Содержимое файла dlq_trigger.bat
cd "C:\Program Files\IBM\WebSphere MQ\bin"
runmqdlq < RULETBL.RUL

Как показано ниже в листинге 7, таблица правил определяется с помощью последовательных функций REASON и ACTION и функции WAIT (NO), которая означает, что утилита DLQ Handler не будет в течение неопределенно долгого времени ждать появления сообщений в очереди DLQ. Сегмент управляющих данных содержит имена входной очереди и менеджера очереди:

Листинг 7. Содержимое таблицы правил RULETBL.RUL
INPUTQ('DEADQ') INPUTQM('IBMQMR') RETRYINT(45) WAIT(NO)
REASON(MQRC_Q_FULL) ACTION(FWD) FWDQ(DLQX) FWDQM(IBMQMR)

В DEADQ менеджера очереди IBMQMR установите функцию запуска в ON, чтобы при поступлении сообщения в DEADQ утилита DLQ Handler активировалась и обрабатывала сообщение в соответствии с таблицей правил, расположенной в файле RULETBL.RUL. Укажите имя процесса, который надо запустить, как processdlq, а имя очереди инициализации — как SYSTEM.DEFAULT.INITIATION.QUEUE:

Листинг 8. Настройка запуска DLQ для каждого входящего сообщения
DEFINE QLOCAL(DEADQ) DESCR('стандартная очередь зависших сообщений WebSphere MQ') 
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE) TRIGTYPE(EVERY) TRIGGER PROCESS('processdlq')
1 : DEFINE QLOCAL(DEADQ) DESCR('стандартная очередь зависших сообщений WebSphere MQ') 
INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE) TRIGTYPE(EVERY) TRIGGER PROCESS('processdlq')
AMQ8006: WebSphere MQ queue created.
       :
DISPLAY QLOCAL(DEADQ) DESCR INITQ TRIGGER TRIGTYPE PROCESS
2 : DISPLAY QLOCAL(DEADQ) DESCR INITQ TRIGGER TRIGTYPE PROCESS
AMQ8409: Display Queue details.
    QUEUE(DEADQ)                            TYPE(QLOCAL)
    DESCR(стандартная очередь зависших сообщений WebSphere MQ)
    INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE)
    TRIGGER                                 PROCESS(processdlq)
    TRIGTYPE(EVERY)

Программа мониторинга запуска считывает запускающие сообщения в очереди инициализации и выполняет операции в соответствии с их содержимым. Менеджер очереди создает запускающее сообщение, копируя информацию из свойств объекта определения процесса, и помещает его в очередь инициализации. Монитор запуска runmqtrm можно запустить как объект серверной службы или как фоновый процесс, запускаемый из командной строки. В листинге 9 показано, как запустить монитор запуска runmqtrm из командной строки:

Листинг 9. Запуск монитора запуска из командной строки
runmqtrm -m IBMQMR -i SYSTEM.DEFAULT.INITIATION.QUEUE

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

Листинг 10. Определение и состояние объекта сервисной службы мониторинга запуска
display svstatus('triggerdlq') all
1 : display svstatus('triggerdlq') all
AMQ8632: Display service status details.
    SERVICE(triggerdlq)                     STATUS(RUNNING)
    PID(9540)                               SERVTYPE(SERVER)
    STARTDA(2011-12-27)                     STARTTI(17.11.53)
    CONTROL(MANUAL)
    STARTCMD(C:\Program Files\IBM\WebSphere MQ\bin\runmqtrm)
    STARTARG(-m IBMQMR)                     STOPCMD( )
    STOPARG( )                              DESCR(запуск the dlq handler)
    STDOUT(C:\IBM\WebSphere\MQ\Log_runmqtrm.txt)
    STDERR(C:\IBM\WebSphere\MQ\Err_runmqtrm.txt)

Если вы определили объект серверной службы в Windows для таких утилит MQ, как монитор запуска или DLQ Handler, установив Control в значение Queue Manager, то для остановки этих процессов нужно остановить менеджер очереди, который, в свою очередь, останавливает соответствующий объект серверной службы. Команды остановки монитора запуска или утилиты DLQ Handler, которую можно было бы передать в качестве аргумента STOPCMD соответствующего объекта серверной службы, не существует.

Процесс мониторинга запуска runmqtrm можно запустить из командной строки, в том числе с аргументами, определяющими имя менеджера очереди и имя очереди инициализации.

Для проверки сделайте так, чтобы в очередь DEADQ менеджера очереди IBMQMR поступали сообщения, приводящие к запуску утилиты DLQ Handler для каждого входящего сообщения, что обеспечивает пересылку сообщений в DLQX согласно показанной выше таблице правил. Вы увидите сообщения в DLQX как вторичные DLQ, IPPROC, OPPROC в очереди DEADQ менеджера IBMQMR после заполнения локальной очереди LOCAL1:

Рисунок 4. Состояние DEADQ и DLQX после запуска утилиты DLQ Handler
DEADQ and DLQX status after DLQ Handler triggered

При попадании сообщения в очередь DLQ запускается утилита DLQ Handler, которая следит за очередью DLQ и обрабатывает недоставленные сообщения в соответствии с таблицей правил. Программа runmqdlq выполняет запуск утилиты DLQ Handler, и DLQ Handler запускается лишь в том случае, если его запустил монитор запуска. Монитор запуска работает в другой оболочке, содержащей папку bin Websphere MQ в переменной пути для исполняемых программ.

Заключение

В любой среде промежуточного ПО, использующей WebSphere MQ, нужно определить очередь DLQ для каждого менеджера очереди, которая будет принимать недоставленные сообщения для их обработки и анализа, чтобы определить причины их недоставки в точку назначения. Утилита DLQ Handler, обрабатывающая недоставленные сообщения, может реализовываться в виде объекта серверной службы или в виде запускаемого процесса. В критически важных системах с высокой загрузкой предпочтительнее реализовывать DLQ Handler в виде объекта серверной службы, но в некоторых случаях лучше запускать DLQ Handler в зависимости от специальных требований. Эта статья поясняет оба сценария, описывая их положительные и отрицательные стороны.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere
ArticleID=832325
ArticleTitle=Применение обработчика очереди зависших сообщений в WebSphere MQ
publish-date=08292012