Я использую этот пример от IBM. Я просто скопировал и вставил код:
https://github.com/ibm-messaging/mq-dev-patterns/blob/master/dotnet/dotNetGet.cs
Я вижу очень странное поведение. Приложение работает нормально и может получать сообщения. Но он отключился ровно через 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 минут бездействия?
Можете ли вы подтвердить, что вы вызываете это в управляемом режиме? (предоставление *SYSTEM
или *USER
в качестве хранилища ключей?
@JoshMc значение репозитория ключей - «* SYSTEM». Поэтому и следуя примеру, свойство "XMSC_WMQ_CONNECTION_MODE" установлено в WMQ_CM_CLIENT=1
Пример кода перехватывает исключения вне цикла обработки сообщений. Если вы хотите переподключиться, когда связанное исключение — 2009, вам нужно будет поймать исключение внутри цикла, проверить, что это 2009 — MQRC_CONNECTION_BROKEN — и переподключиться. Соединение может быть разорвано по ряду причин и, скорее всего, связано с сетью или брандмауэром.
Существует ли брандмауэр между вами и администратором очередей MQ? Я хотел бы спросить вас, сетевики, отключает ли брандмауэр соединение.
@chughts, почему IBM не предоставляет образцы с включенным переподключением клиента MQ?
JoshMc Хороший вопрос. Я поднял вопрос о репозитории MQ-Pattern — github.com/ibm-messaging/mq-dev-patterns/issues/4
@chughts, спасибо, что открыли это.
Описанные вами симптомы соответствуют 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.
Чтобы дать некоторые сведения о том, как все должно работать:
HBINT
), который представляет собой значение в секундах. Согласованное HBINT
всегда является наивысшим значением, согласованным между SVRCONN
и клиентским приложением.SVRCONN
HBINT
имеет значение по умолчанию 300
.HBINT
ТАЙМ-АУТ рассчитывается одним из двух способов:
HBINT
меньше 60, ТАЙМ-АУТ удваивается HBINT
. (полученный тайм-аут составляет HBINT секунд после прохождения HBINT)HBINT
больше или равно 60, ТАЙМ-АУТ равен HBINT
+ 60. (тайм-аут приема составляет 60 секунд после прохождения HBINT).HBINT
промежутка времени, клиент должен отправить Heart Beat диспетчеру очередей, который должен ответить. Клиент должен подождать время тайм-аута приема, чтобы получить Heart Beat.HBINT
, прежде чем отправить Heart Beat клиенту.APAR IT26614 устраняет следующие три проблемы:
Документировано, что в неуправляемом или управляемом режиме, если вы не используете CCDT, HBINT
будет использовать значение канала SVRCONN
. На самом деле, если не использовать CCDT, HBINT
на стороне клиента по умолчанию будет 300
, так что это самый низкий HBINT
, который вы увидите.
В частности, для Managed .NET клиентская сторона HBINT
не может быть ниже SVRCONN
HBINT
соединение завершится с ошибкой 2059. Эта проблема возникает как с CCDT, так и без него.
CLNTCONN
HBINT
на значение меньше, чем SVRCONN
HBINT
SVRCONN
HBINT
установлен на 301
или выше
Для 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 я подозреваю, что происходит следующее:
Вы упомянули, что видели это только через 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
секунд, если соединение потеряно. Повторное подключение не применяется к начальному подключению к администратору очередей, оно применяется только после того, как вы подключитесь.
Какую ошибку вы видите в журналах ошибок администратора очередей?