Взаимодействие менеджеров очередей и клиентские подключения в WebSphere MQ

7.4.10. Допустимые пары объектов – распределенных каналов сообщений

Агенты MCA, созданные из описанных канальных объектов, могут объединяться с образованием канала лишь в некоторых сочетаниях. Допустимые комбинации и порядок их применения мы рассмотрим в этом разделе лекции.

Каналы sender-receiver

Такой канал может инициироваться лишь со стороны отправителя.

Для подключения к одному объекту receiver-канала в составе менеджера можно использовать целый ряд объектов sender-каналов, описанных на различных менеджерах очередей сообщений.

Типичным является описание на менеджере единственного объекта – receiver-канала. Для связи с упомянутым менеджером все менеджеры в составе инфраструктуры располагают sender-каналом, имеющим то же имя, что и receiver-канал.

Каналы requester-server

Каналы такого рода могут инициироваться на стороне requester-канала или – опционально – на стороне server-канала, если в нем определено полностью название соединения.

Каналы requester-server не требуют, чтобы requester-канал, инициирующий соединение, находился в системе с конкретным именем соединения. Это позволяет описать множество одноименных requester-каналов в составе различных менеджеров, каждый из которых сможет запрашивать сообщения из единой транспортной очереди одного и того же удаленного менеджера. Впрочем, одновременно активным и извлекающим сообщения из транспортной очереди может являться только один канал, ведущий к requester-каналу.

Каналы requester-sender

Такой канал схож с каналом requester-server с полностью определенным объектом server-канала. Однако, после того как соединение было инициировано requester-каналом, связь разрывается и формируется снова sender-каналом с использованием хранящегося внутри него названия соединения.

Sender-каналу данное решение позволяет гарантировать, что он связан с requester-каналом под управлением конкретного менеджера.

Каналы server-receiver

Функционально эквивалентны паре sender-receiver. Соединение инициируется со стороны server-канала, а значит, server-канал должен иметь полностью определенное название соединения.

7.4.11. Ошибки доставки сообщений

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

Доставка сообщения может дать сбой по следующим причинам.

• Неудачное окончание разрешения названия очереди при попытке ее открытия. Как было сказано в "Взаимодействие менеджеров очередей и клиентские подключения в WebSphere MQ" "Отправка сообщений", названия очереди и менеджера очередей сообщений, которые служат для открытия очереди с целью размещения сообщения, содержатся в заголовке транспортной очереди. Процедуру разрешение названия и влияние на нее всех типов объектов-очередей мы обсудили в "Технические основы организации очередей сообщений" "Разрешение названия очереди".
• Установленная при разрешении очередь, которая может являться локальной очередью менеджера очередей сообщений или транспортной очередью, представляющей следующий пункт назначения на маршруте к месту получения сообщения, уже содержит максимально допустимое количество сообщений.
• Размещение сообщений в очереди блокировано.

Меры, предпринимаемые агентом, определяются атрибутами канального объекта агента и атрибутом "очередь недоставленных сообщений" ( DEADQ – dead letter queue) объекта-менеджера. Вкратце эти шаги таковы.

1. Поскольку в силу своей природы часть сбоев доставки – например, нахождение в очереди предельного количества сообщений – может не повторяться, MCA-получатель может попытаться разместить сообщение вновь. Количество повторных попыток размещения сообщения агентом определяется атрибутом "число попыток на сообщение" ( MRRTY – message retry) того объекта-канала, где описан MCA-получатель. Интервал между попытками определяется атрибутом "таймер попыток на сообщение" ( MRTMR – message retry timer) этого же канала.
2. Если атрибут "очередь недоставленных сообщений" ( DEADQ ) объекта-менеджера очередей задан, MCA-получатель попытается открыть очередь, имеющую указанное название. Если это ему удастся, к сообщению будет добавлен заголовок недоставленного сообщения ( MQDLH ), и оно будет размещено в этой очереди.

   Заголовок недоставленного сообщения содержит информацию об ошибке. В нее входят название очереди и менеджера очередей сообщений из заголовка транспортной очереди. Также в заголовок недоставленного сообщения входит и код причины, полученный при неудачной попытке открыть очередь для размещения сообщения. Такие коды причин мы обсуждали в "Технические основы организации очередей сообщений" "Коды завершения и причин".
3. Если для текущего менеджера очередь недоставленных сообщений не задана или не существует, действие зависит от факта, используются ли для передачи сообщений единицы работы. Как говорилось в "Взаимодействие менеджеров очередей и клиентские подключения в WebSphere MQ" "Пакеты", единицы работы задействуются при передаче постоянных сообщений; применительно же к непостоянным они используются лишь при задании нормальной (normal) скорости работы канала.

Если для доставки сообщений единицы работы не применяются, непостоянное сообщение аннулируется.

Если для доставки сообщений используются единицы работы, сообщение возвращается в транспортную очередь на стороне отправителя. Канал, как было сказано в "Взаимодействие менеджеров очередей и клиентские подключения в WebSphere MQ" "Понятие состояния канала", переходит в состояние RETRYING. При этом он пытается доставить сообщение снова – каждый раз при повторении перезапуска. Когда же заданное для канала количество повторных попыток будет исчерпано, он перейдет в состояние STOPPED, и перезапуск канала должен производиться вручную. Движение сообщений в канале будет прекращено, пока нельзя будет доставить сообщение, не будет указана очередь недоставленных сообщений для менеджера либо сообщение не будет вручную удалено из транспортной очереди.

7.4.12. Работа с очередью недоставленных сообщений

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

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

Подходы к обработке данной очереди включают следующее.

• Регулярный просмотр администратором.

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

  1. выделите в навигаторе папку Queues менеджера очередей сообщений;
  2. щелкните правой кнопкой мыши по очереди недоставленных сообщений на панели содержимого Queues ;
  3. выберите в меню Browse Messages ;
  4. щелкните правой кнопкой по сообщению из таблицы;
  5. выберите в меню Properties ;
  6. выберите раздел Dead-letter header.
• Выполнение действия по триггеру, который срабатывает всегда, как только в очереди недоставленных сообщений появляются сообщения.

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

  К разряду триггеров, которые можно использовать в данном случае, относятся:

  • триггеры типа FIRST с большим, определенным для менеджера триггерным интервалом. Они инициируют регулярное выполнение приложения, если в очереди недоставленных сообщений имеются сообщения;
  • триггеры типа EVERY. Они инициируют выполнение приложения всякий раз при поступлении в очередь нового сообщения.
• Применение обработчика очереди недоставленных сообщений, входящего в WebSphere MQ.

  С учетом набора правил, настроенных при запуске обработчика, он может автоматически выполнять действия над сообщениями, прибывающими в очередь недоставленных сообщений. Для ознакомления с обработчиком очереди недоставленных сообщений из WebSphere MQ читайте руководство WebSphere MQ Intercommunication, SC34-6587.
• Применение обработчика очереди недоставленных сообщений собственной разработки.

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

7.4.13. Инициирование канала

Перезапуск каналов сообщений не производится WebSphere MQ автоматически, если каналы становятся неактивны по достижении интервала разъединения или при перезапуске менеджера.

Число каналов в составе менеджера может быть велико, и ручной запуск с использованием MQSC или WebSphere MQ Explorer в инфраструктуре взаимосвязанных менеджеров может оказаться неэффективным.

WebSphere MQ для платформ Windows и UNIX содержат процесс-инициатор каналов, автоматически запускающий их при поступлении сообщений в транспортные очереди.

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

Инициатор каналов WebSphere MQ можно запустить по управляющей команде WebSphere MQ runmqchi. Впрочем, инициатор каналов по умолчанию предоставляется WebSphere MQ и автоматически запускается менеджером очередей сообщений.

Этот модуль инициатора каналов по умолчанию может быть заблокирован установкой параметра SCHINIT (start channel initiator) объекта-менеджера очередей в MANUAL.

Используемый по умолчанию инициатор каналов наблюдает за очередью неудачных попыток инициирования SYSTEM.CHANNEL.INITQ.

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

• Активируйте триггеры: TRIGGER.
• Установите тип триггера "для первого сообщения": TRIGTYPE(FIRST).
• Данные триггера – в значение названия канала: TRIGDATA('TO.remote.qmgr').
• Очередь инициации – в SYSTEM.CHANNEL.INITQ: INITQ(SYSTEM.CHANNEL.INITQ).

7.5. Автоопределение каналов

Менеджер очередей сообщений можно настроить так, чтобы в ответ на запросы соединения от MCA канальные объекты создавались автоматически.

Чтобы разрешить автоопределение каналов менеджера очередей сообщений, установите атрибут "автоопределение каналов" ( CHAD – channel auto-definition) объекта-менеджера в значение ENABLED.

7.5.1. Автоопределение клиентских каналов

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

После автоопределения канала объект-канал функционирует так, как будто создавался вручную. Атрибуты канального объекта серверных подключений основаны на атрибутах автоматически формируемого менеджером очередей сообщений канального объекта серверных подключений SYSTEM.AUTO.SVRCONN.

7.5.2. Автоопределение распределенных каналов сообщений

Если при попытке удаленного менеджера установить подключение, используя объект – sender-канала или полностью заданный объект – server-канала, соответствующий receiver-канал или requester-канал с требуемым названием на менеджере отсутствует, автоматически создается receiver-канал.

После автоопределения канала объект-канал функционирует так, как будто создавался вручную. Атрибуты объекта – receiver-канала основаны на атрибутах автоматически формируемого менеджером очередей сообщений объекта receiver-канала SYSTEM.AUTO.RCVR.