Сообщение MQ задерживается на несколько дней - PullRequest
Новая
       31

Сообщение MQ задерживается на несколько дней

1 голос
/ 31 марта 2011

Мы используем IBM WebSphere MQ для сообщений SWIFT. Когда получено сообщение SWIFT, оно обрабатывается и помещается в локальные очереди в процессе обработки. Это как следующее:

Внешний мир> Q1> Приложение> Q2> Приложение> Q3> Приложение

Очереди являются локальными очередями. Но произошла значительная задержка, когда сообщение достигает Приложения из Q1 / Q2 / Q3 ... как дни. И это происходит произвольно. Мы понятия не имеем, почему это происходит. Большинство сообщений проходят довольно быстро, но есть несколько из них через 3-4 дня, которые приходят с опозданием.

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

Кто-нибудь сталкивался с подобной проблемой раньше? Любая помощь приветствуется.

Спасибо, Midhun.

1 Ответ

1 голос
/ 04 апреля 2011

Существует несколько способов, с помощью которых сообщения WebSphere MQ могут быть отложены, а диагностика может потребовать небольшой детективной работы. Вот несколько наиболее распространенных причин:

  1. Сообщение застряло в точке синхронизации. Хотя это было бы необычно для сообщения сидеть под syncpoint в течение нескольких дней, я видел, как это происходит. Проблема заключается в том, что некоторые приложения предназначены для пакетирования нескольких сообщений в одной транзакции, и когда сообщения не поступают в пакетном множественном числе, остальные сообщения сидят и ждут, пока другое сообщение (я) прибудут и закроют пакет.
  2. Сообщение застряло в точке синхронизации. В другом случае логика программы не фиксирует точку синхронизации, пока не будет прочитано следующее сообщение. Когда несколько потоков обрабатывают сообщения, распределение нагрузки не обязательно является равномерным по всем потокам, и один из них может нуждаться в сообщениях, если загрузка мала.
  3. Сообщение осиротело при просмотре. В этом случае сообщение приходит с более высоким приоритетом, чем текущий курсор просмотра. Если интервал повторного сканирования установлен слишком высоким, а объем трафика также высоким, может пройти некоторое время, прежде чем курсор обзора вернется в начало очереди.
  4. Ошибка программы. Вы не упомянули, какую версию клиента и сервера WMQ вы используете (возможно, обе версии 7.0!), Но иногда возникают проблемы, приводящие к зависанию потоков. Они могут связать сообщение под syncpoint. Всегда полезно перейти на последний пакет FixPack для вашей версии и проверить ссылку «Проблемы, исправленные в ...», чтобы узнать, решает ли APAR вашу конкретную проблему. Если это так, примените последний пакет исправлений.

Чтобы начать диагностику, используйте команду DIS QSTATUS, чтобы отобразить количество дескрипторов ввода и вывода в очереди, возраст сообщения и все оставшиеся единицы работы. Вы также можете использовать выход в SupportPac MA0W , чтобы получить удобочитаемую трассировку всех вызовов API в данной очереди. Это может быть чрезвычайно полезным диагностическим инструментом, поскольку вы можете точно определить, как долго сообщение находилось под точкой синхронизации, постоянно ли оно возвращается и перечитывается, какие параметры используются для вызова API и т. Д. Вы даже можете ограничить трассировку в определенные очереди или определенные потоки, что полезно, если вам нужно какое-то время запустить его.

...