Клиент IBM MQ отключается через 10 минут: IBM.XMS.IllegalStateException

Я использую этот пример от IBM. Я просто скопировал и вставил код:

https://github.com/ibm-messaging/mq-dev-patterns/blob/master/dotnet/dotNetGet.cs

  • Я подключаюсь к серверу MQ версии 9.0.0.5.
  • Я использую консольное приложение .Net Framework 4.6.1.
  • Клиент MQ, установленный на моих локальных машинах, — 9.1.0.1.

Я вижу очень странное поведение. Приложение работает нормально и может получать сообщения. Но он отключился ровно через 10 минут. Это всегда 10 минут.

Это пойманная ошибка:

IBM.XMS.IllegalStateException: Failed to get a message from destination MY_QUEUE.
IBM MQ classes for XMS attempted to perform an MQGET; however IBM MQ reported an error.
Use the linked exception to determine the cause of this error.
   at IBM.XMS.Client.Impl.XmsMessageConsumerImpl.ReceiveInboundMessage(Int64 timeout)
   at IBM.XMS.Client.Impl.XmsMessageConsumerImpl.Receive(Int64 millis)
   at Mq_Get_Tests.SimpleConsumer.ReceiveMessages() in C:\Users\osotorrio\Projects\Temporal\Mq_Get_Tests\Mq_Get_Tests\SimpleConsumer.cs:line 137
Linked Exception : CompCode: 2, Reason: 2009*

Отсутствуют ли в примере IBM некоторые параметры конфигурации, позволяющие клиенту повторно подключиться после 10 минут бездействия?

Какую ошибку вы видите в журналах ошибок администратора очередей?

subbaraoc 08.07.2019 17:03

Можете ли вы подтвердить, что вы вызываете это в управляемом режиме? (предоставление *SYSTEM или *USER в качестве хранилища ключей?

JoshMc 08.07.2019 17:35

@JoshMc значение репозитория ключей - «* SYSTEM». Поэтому и следуя примеру, свойство "XMSC_WMQ_CONNECTION_MODE" установлено в WMQ_CM_CLIENT=1

osotorrio 08.07.2019 17:52

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

chughts 08.07.2019 18:16

Существует ли брандмауэр между вами и администратором очередей MQ? Я хотел бы спросить вас, сетевики, отключает ли брандмауэр соединение.

Roger 08.07.2019 18:51

@chughts, почему IBM не предоставляет образцы с включенным переподключением клиента MQ?

JoshMc 11.07.2019 13:11

JoshMc Хороший вопрос. Я поднял вопрос о репозитории MQ-Pattern — github.com/ibm-messaging/mq-dev-patterns/issues/4

chughts 11.07.2019 18:10

@chughts, спасибо, что открыли это.

JoshMc 12.07.2019 22:02
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
3
8
1 685
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Описанные вами симптомы соответствуют APAR IT26614: клиентский канал MQ dotnet (.NET) аварийно завершается при достижении такта (HBINT).

The fix is targeted for delivery in the following PTFs:

Version    Maintenance Level
v8.0       8.0.0.13
v9.0 LTS   9.0.0.7
v9.1 CD    9.1.3
v9.1 LTS   9.1.0.3

По состоянию на 7 августа 2019 г. выпущены версии 9.0.0.7 и 9.1.0.3, которые можно загрузить с MQC9: клиенты IBM MQ V9 или MQC91: Клиенты IBM MQ.


Чтобы дать некоторые сведения о том, как все должно работать:

  1. Клиентское приложение MQ при подключении к администратору очередей будет согласовывать интервал подтверждения (HBINT), который представляет собой значение в секундах. Согласованное HBINT всегда является наивысшим значением, согласованным между SVRCONN и клиентским приложением.
    Примечание: A SVRCONNHBINT имеет значение по умолчанию 300.
  2. На основе HBINT ТАЙМ-АУТ рассчитывается одним из двух способов:
    1. Если согласованное HBINT меньше 60, ТАЙМ-АУТ удваивается HBINT. (полученный тайм-аут составляет HBINT секунд после прохождения HBINT)
    2. Если согласованное HBINT больше или равно 60, ТАЙМ-АУТ равен HBINT + 60. (тайм-аут приема составляет 60 секунд после прохождения HBINT).
  3. Если нормальный трафик не был получен от диспетчера очередей в течение HBINT промежутка времени, клиент должен отправить Heart Beat диспетчеру очередей, который должен ответить. Клиент должен подождать время тайм-аута приема, чтобы получить Heart Beat.
  4. Диспетчер очередей также может инициировать Heart Beat для клиента, но для предотвращения дополнительного трафика администратор очередей ждет на пять секунд больше, чем согласовано HBINT, прежде чем отправить Heart Beat клиенту.

APAR IT26614 устраняет следующие три проблемы:

  1. Документировано, что в неуправляемом или управляемом режиме, если вы не используете CCDT, HBINT будет использовать значение канала SVRCONN. На самом деле, если не использовать CCDT, HBINT на стороне клиента по умолчанию будет 300, так что это самый низкий HBINT, который вы увидите.

  2. В частности, для Managed .NET клиентская сторона HBINT не может быть ниже SVRCONNHBINT соединение завершится с ошибкой 2059. Эта проблема возникает как с CCDT, так и без него.

    • с CCDT вы не можете установить CLNTCONNHBINT на значение меньше, чем SVRCONNHBINT
    • без CCDT вы будете затронуты, если SVRCONNHBINT установлен на 301 или выше
  3. Для Managed .NET тайм-аут получения на стороне клиента рассчитывался в миллисекундах, а не в секундах. В данном случае дефект присутствовал согласно IBM в течение длительного времени, но не проявлялся, пока APAR IT16167: управляемое клиентское приложение .NET не отправляет запрос пульса администратору очередей. не был введен в 8.0.0.10 и 9.0.0.4 (IBM также подтвердила, что это присутствует в GA 9.1.0.0). Причина, по которой раньше это не было проблемой, заключалась в том, что Managed .NET никогда не инициировал Heart Beat, диспетчер очередей всегда отправлял Heart Beat в HBINT + 5 секунд, и клиент .NET отвечал. Как только это было исправлено, обнаружился просчет времени ожидания приема.


На основе управляемого клиента XMS.NET версии 9.1.0.1 я подозреваю, что происходит следующее:

  1. HBINT согласовывается до 300 секунд независимо от того, что установлено SVRCONN HBINT.
  2. Клиент Managed XMS.NET отправит диспетчеру очередей сообщение Heart Beat после того, как в течение 300 секунд от него ничего не будет получено.
  3. На этом этапе управляемый клиент XMS.NET будет ждать ответа от диспетчера очередей только 60 мс.
  4. Если управляемый клиент XMS.NET не получит ответ в течение 60 мс, он вернет приложению ошибку 2009.
  5. В журналах ошибок диспетчера очередей будет отображаться сообщение AMQ9209 с сообщением «Произошла ошибка при получении данных от 'dnsname (xx.xx.xx.xx)' по TCP/IP.

Вы упомянули, что видели это только через 10 минут (600 секунд), но я видел это с любым 300-секундным интервалом в зависимости от задержки сети. Если вы подключаетесь к администратору очередей на том же сервере или в том же сегменте локальной сети, вы можете никогда не столкнуться с этой проблемой. Если вы подключаетесь через канал WAN с высокой задержкой, это может происходить каждые 300 секунд. Если вы подключены через сегмент с около 30 мс, вы можете видеть его с перерывами.

Я предлагаю вам попробовать управляемый клиент XMS.NET 9.0.0.7 или 9.1.0.3 и посмотреть, решит ли он проблему для вас, поскольку в этих выпусках он будет ждать ответа Heart Beat от диспетчера очередей полных 60 секунд.


Если вы хотите добавить повторное подключение к образцу, которое замаскирует проблему, если вы не используете версию MQ, включающую APAR IT26614, вы можете использовать следующие параметры:

cf.SetIntProperty(XMSC.WMQ_CLIENT_RECONNECT_OPTIONS, XMSC.WMQ_CLIENT_RECONNECT);
cf.SetIntProperty(XMSC.WMQ_CLIENT_RECONNECT_TIMEOUT, XMSC.WMQ_CLIENT_RECONNECT_TIMEOUT_DEFAULT);
//Note that XMSC.WMQ_CLIENT_RECONNECT_TIMEOUT_DEFAULT is 1800

Обратите внимание, что даже если вы используете версию MQ с APAR IT26614, описанное выше является хорошей практикой, так как клиент Managed XMS.NET автоматически попытается повторно подключиться к диспетчеру очередей в течение XMSC.WMQ_CLIENT_RECONNECT_TIMEOUT секунд, если соединение потеряно. Повторное подключение не применяется к начальному подключению к администратору очередей, оно применяется только после того, как вы подключитесь.

Другие вопросы по теме