Симптомы, которые вы описываете, похоже, соответствуют 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
По состоянию на 8 июля 2019 года была выпущена только 9.0.0.7, которую можно загрузить с MQC9: клиенты IBM MQ V9
Чтобы дать некоторое представление о том, каквсе должно работать:
- Клиентское приложение MQ при подключении к администратору очередей согласовывает интервал пульса (
HBINT), который является значением в секундах.Согласованный HBINT всегда является наибольшим значением, согласованным между SVRCONN и клиентским приложением.
Примечание: A SVRCONN HBINT имеет значение по умолчанию 300. - На основе
HBINT время ожидания рассчитывается одним из двух способов: - Если согласованное значение
HBINT меньше 60, время ожидания равно 2x HBINT.(полученный тайм-аут составляет HBINT секунд после того, как прошел HBINT) - Если согласованный
HBINT больше или равен 60, время ожидания равно HBINT + 60. (тайм-аут приема составляет 60 секунд послеHBINT прошел).
- Если от администратора очередей в течение
HBINT времени не было получено нормального трафика, клиент должен отправить Heart Beat администратору очереди, который должен ответить,Клиент должен дождаться истечения времени ожидания приема для получения Heart Beat. - Администратор очередей также может инициировать Heart Beat для клиента, но для предотвращения дополнительного трафика администратор очередей ожидает на пять секунд больше, чемсогласованный
HBINT перед отправкой сердцебиения клиенту.
APAR IT26614 исправляет следующие три проблемы:
В неуправляемом илиВ управляемом режиме задокументировано, что если вы не используете CCDT, HBINT будет использовать значение канала SVRCONN.В действительности, если не использовать CCDT, HBINT на стороне клиента по умолчанию будет 300, поэтому это самое низкое значение HBINT, которое вы увидите.
Специально для Managed .NETна стороне клиента HBINT не может быть ниже SVRCONN HBINT, соединение с 2059 не будет установлено. Эта проблема касается как с, так и без CCDT.
- с CCDT, который вы не можете установить
CLNTCONN HBINT до значения, меньшего SVRCONN HBINT - без CCDT, на вас повлияет, если для
SVRCONN HBINT установлено значение 301 или выше
Специфично для управляемого .NET тайм-аут приема на стороне клиента рассчитывался в миллисекундах, а не секундах.В этом случае дефект присутствовал в соответствии с IBM в течение длительного времени, но не появлялся до тех пор, пока APAR IT16167: Управляемое клиентское приложение .NET не отправляет запрос пульса диспетчеру очереди , введенному в 8.0.0.10.и 9.0.0.4 (IBM также подтвердила, что это присутствует в GA 9.1.0.0).Причина, по которой раньше это не было проблемой, заключалась в том, что Managed .NET никогда не инициировал сердцебиение, менеджер очередей всегда отправлял сердцебиение со скоростью HBINT + 5 секунд, а клиент .NET отвечал.Как только это было исправлено, просчет времени ожидания приема представился.
Основываясь на версии 9.1.0.1 Managed XMS.NET клиента, я подозреваю, что это происходит:
- HBINT согласовывается до 300 секунд независимо от того, что установлено SVRCONN HBINT.
- Управляемый клиент XMS.NET отправит Heart Beat менеджеру очередей после того, как он ничего не получил отадминистратор очередей в течение 300 секунд.
- В этот момент клиент Managed XMS.NET будет ожидать ответа от администратора очередей только 60 мс.
- Если клиент Managed XMS.NET не получаетответ через 60 мс вернет приложению ошибку 2009 года.
- В журналах ошибок администратора очередей будет отображаться AMQ9209 с сообщением «Произошла ошибка при получении данных от« dnsname (xx.xx.xx.xx) »в течениеTCP / IP.
Вы упоминаете, что видели это только через 10 минут (600 секунд), но я видел это через любые 300-секундные интервалы, основанные на задержке сети.Если вы подключаетесь к администратору очередей на том же сервере или в том же сегменте локальной сети, вы можете никогда не увидеть эту проблему.Если вы подключаетесь по глобальной сети с высокой задержкой, это может происходить каждые 300 секунд.Если вы подключены к сегменту, близкому к 30 мс, вы можете видеть его периодически.
Я предлагаю вам попробовать клиент 9.0.0.7 Managed XMS.NET и посмотреть, решит ли он проблему для вас с этого выпуска.он будет ждать полных 60 секунд ответа Heart Beat от администратора очередей.
Если вы хотите добавить повторное подключение к образцу, который бы маскировал проблему, если бы не использовалась версия MQ, включающая APARIT26614, вы можете использовать следующие настройки:
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 секунд, если соединение потеряно.Повторное подключение не применяется к начальному подключению к администратору очередей, оно применяется только после того, как вы подключились.