Устранение неполадок

12.4. Общие проблемы с доступом к инфраструктуре

В этом разделе рассказывается о диагностике и разрешении проблем, возникающих при обращении к инфраструктуре WebSphere MQ.

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

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

1. Убедитесь, что менеджер очередей работает, например так:
   • с помощью команды dspmq (в Windows и UNIX) либо WebSphere MQ Explorer;
   • с помощью команды WRKMQM (в iSeries).
2. Изучите код возврата операции подключения.
3. В случае клиентских приложений убедитесь, что у целевого менеджера очередей работает слушатель. Убедитесь в том, что для менеджера очередей указан верный транспорт (обычно TCP) и имя подключения. Если используется таблица CCDT, проверьте, верно ли указан путь к ней. Для JMS-приложений его указывают в объекте connection factory в каталоге, к которому обращаются через JNDI. Этот каталог должен быть доступен приложению.
4. Для клиентских приложений проверьте, соответствует ли имя используемого канала имени канала серверного подключения из менеджера очередей; также проверьте, включено ли автоопределение канала (channel auto-definition, CHAD) для этого менеджера очередей. В любом случае имена каналов должны совпадать (учтите: имена каналов чувствительны к регистру).
5. Проверьте правильность (вплоть до регистра) имени менеджера очередей, указанного приложением. Для клиентских приложений, подключающихся с использованием CCDT, проверьте правильность значения атрибута "имя менеджера очередей" ( QMNAME ) объекта клиентского подключения, объявленного в менеджере очередей, создавшем CCDT.
6. Изучите системные журналы ошибок WebSphere MQ.
7. Проанализируйте журналы ошибок менеджера очередей, чтобы определить, в каком компоненте возникают сбои.
8. Проверьте наличие у учетной записи пользователя, под которой приложение пытается подключиться к менеджеру очередей, соответствующих полномочий.

12.4.2. Устранение неполадок отправки сообщений

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

1. Изучите код возврата операций открытия очереди и размещения сообщений.
2. Проверьте правильность имен объекта очереди и (необязательно) менеджера очередей, указанных приложением, открывающим очередь (учтите, что имена объектов чувствительны к регистру).
3. Убедитесь, что целевая очередь доступна менеджеру очередей, существует необходимая транспортная очередь и объявлен локальный объект удаленной очереди.
4. Если целевая очередь обслуживается менеджером очередей в составе кластера, убедитесь, что ее объект опубликован в кластере удаленным менеджером очередей, а также в наличии у обоих менеджеров очередей связи с полным репозиторием кластера.
5. Проверьте правильность параметров, с которыми приложение открывает очередь, в частности убедитесь, что очередь открывается для вывода.
6. С помощью табл. 6.1 определите объект, применяемый для проверки полномочий в комбинации с именем менеджера очередей, указанным приложением. Убедитесь, что учетная запись, под которой приложение пытается подключиться, обладает полномочиями для добавления сообщений в нужную очередь. Чтобы определить контекст приложения, можно вывести сведения о подключении к менеджеру очередей, пока подключение существует, например командой DISPLAY CONN(*) ALL.
7. Проверьте параметры добавляемого сообщения, в частности указана ли точка синхронизации ( syncpoint ), определяющая включение добавления сообщения в единицу работы. Если точка синхронизации указана, проверьте, зафиксирована ли единица работы.
8. Проверьте, что во всех очередях на пути к очереди назначения разрешен вывод.
9. Убедитесь, что значения атрибутов "максимальная длина сообщений" ( MAXMSGL ) локальной очереди и всех транспортных очередей, а также менеджера очередей достаточно велики.
10. Изучите журналы ошибок менеджера очередей, к которому подключено приложение.

12.4.3. Устранение неполадок извлечения сообщений

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

1. Изучите код возврата операций открытия очереди и извлечения сообщений.
2. Убедитесь, что в менеджере очередей, к которому подключено сообщение, существует подходящий объект локальной очереди или модельной очереди.
3. Проверьте правильность имени объекта, указанного приложением, открывающим очередь (учтите, что имена объектов чувствительны к регистру).
4. Проверьте правильность параметров, с которыми приложение открывает очередь. В частности, очередь должна открываться для ввода, ввода с монопольным доступом или для просмотра. С помощью табл. 6.1 определите объект, применяемый для проверки полномочий в комбинации с именем менеджера очередей, указанным приложением. Убедитесь, что учетная запись, под которой приложение пытается подключиться, обладает полномочиями для извлечения сообщений из нужной очереди. Чтобы определить контекст приложения, можно вывести сведения о подключении к менеджеру очередей, пока подключение существует, например командой DISPLAY CONN(*) ALL.
5. Проверьте правильность параметров получения сообщений, в частности указана ли точка синхронизации, определяющая включение извлечения сообщения в единицу работы. Если точка синхронизации указана, проверьте, зафиксирована ли единица работы.
6. Убедитесь, что буфер, предоставляемый приложением, достаточно велик для приема сообщения (если только параметры извлечения не допускают прием усеченных сообщений).
   Примечание. Если извлечение оканчивается неудачей из-за недостаточной емкости буфера, приложению возвращается размер сообщения. После этого приложение может повторить операцию, выделив буфер большего размера.
7. Проверьте, имеются ли сообщения в очереди, не получают ли их другие приложения, а также соответствуют ли параметры поиска искомым сообщениям.
   Примечание. Если полю version в структуре, содержащей параметры извлечения сообщений, не присвоено значение 2 или 3, а параметры поиска не определены, идентификатор сообщения и корреляционный идентификатор, которые передаются операции get, необходимо сбрасывать после извлечения каждого сообщения.
8. Убедитесь, что отправка требуемых сообщений в очередь зафиксирована. Возможные причины возникновения незафиксированных сообщений: приложение не зафиксировало единицу работы после размещения сообщения под управлением точки синхронизации; канал связи с менеджером очередей находится в состоянии INDOUBT ; другое приложение получило сообщение под управлением точки синхронизации, но не зафиксировало единицу работы.
   Примечание. Проверить наличие незафиксированных сообщений в очереди можно при помощи команды MQSC DISPLAY QSTATUS либо щелкнув правой кнопкой очередь в WebSphere MQ Explorer и выбрав Status.
9. Изучите журналы ошибок менеджера очередей, к которому подключено приложение.

12.4.4. Устранение общих неполадок триггеров

Существует ряд правил для триггеров, исполнение которых необходимо для генерации триггерных сообщений в очереди инициации при поступлении сообщений в очередь, для которой происходит инициация. Подробнее см. в разделе "Starting WebSphere MQ applications using triggers" руководства WebSphere MQ Application Programming Reference, SC34-6596.

12.4.5. Поиск сообщений, отправленных в инфраструктуру

Менеджеры очередей поддерживают механизм под названием трассировка ( traceroute ), позволяющий тестировать маршруты, пролегающие сквозь инфраструктуру менеджеров очередей WebSphere MQ V6.0, которые возвращают трассировочную информацию приложению trace-route.

Trace-route использует функции отчетов об активности, поддерживаемые менеджерами очередей WebSphere MQ V6.0. Эта функция заключается в генерации компонентами менеджера очередей, такими как MCA, отчетов об активности при выполнении любых действий над сообщениями.

Подробнее о trace-route и отчетах об активности см. в разделе "Message monitoring" руководства Monitoring WebSphere MQ, SC34-6593.

Общие методы поиска сообщений

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

1. Учтите, что непостоянные сообщения могут быть потеряны. Это бывает при перезапуске менеджеров очередей, отсутствии очередей недоставленных сообщений, из-за слишком большого размера сообщений, а также при сбоях сетевых каналов связи, по которым передаются такие сообщения.
2. Убедитесь, что у всех менеджеров очередей настроены очереди недоставленных сообщений. Проверьте эти очереди, просмотрев их.
3. Проверьте наличие в маршруте каналов с состоянием, отличным от RUNNING, либо с неопределенным состоянием (неактивных каналов).
4. Просмотрите транспортную очередь менеджера очередей, к которому приложение было подключено в момент генерации сообщения, затем проверьте следующие транспортные очереди на потенциальном маршруте приложения (в случае кластера менеджеров очередей – SYSTEM.CLUSTER.TRANSMIT.QUEUE ).
5. Убедитесь, что для всех менеджеров очередей, транспортных очередей, каналов и целевых очередей назначения указана достаточно большая максимальная длина сообщения (особенно если размер сообщения больше 4 Мб).
6. Проверьте наличие незафиксированных сообщений во всех транспортных очередях и целевой очереди. Если таковые обнаружатся, проверьте, нет ли каналов в состоянии INDOUBT и приложений с незафиксированными единицами работы, содержащими операции получения данных сообщений.

Маршрутизация сообщений по инфраструктуре

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

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

Для следующих на маршруте сообщения менеджеров разрешение имен очередей выполняется на основе имени очереди, а также имени менеджера очередей, полученного предыдущим менеджером в результате разрешения имен. Эта информация передается по каналу в заголовке транспортной очереди. Агент канала-приемника (MCA) открывает нужную очередь, ориентируясь на сведения из этого заголовка, аналогично тому, как это делают приложения.

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

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