Это странно и несколько тревожно из-за надежного обмена сообщениями. Я надеюсь, что что-то упустил.
Сегодня это стало известно только из-за известных сбоев сети. Это дает мне хорошую возможность взглянуть на некоторую отказоустойчивость.
В потоке 1 мы отправляем сообщение в очередь, управляемую менеджером очередей. Этот код:
using (MQQueueManager qMgr = new MQQueueManager(_queueManager, _connectionProperties))
{
// send message
}
Просто "зависает" на администраторе очередей. Как в, кажется, запустить, а затем тайм-аут. Может быть, он работает в потоке, и поток падает.
Мы бы ничего не знали, если бы у нас не было второго потока, слушающего другую очередь.
У нас есть та же самая конструкция в потоке получения:
using (MQQueueManager qMgr = new MQQueueManager(_queueManager, _connectionProperties))
{
// listen for message
}
Но это выдает MQException
с кодом ошибки 2009. Это указывает на проблему с сетью. (http://www -01.ibm.com / поддержка / docview.wss? UID = swg21472342 )
Однако, опять же, QueueManager
во втором потоке, кажется, раскручивает свой собственный поток, в который генерируется исключение, в результате чего не может его перехватить и отреагировать.
Что-то нам не хватает?
Обновление
Вот мои свойства подключения:
Hashtable connectionProperties = new Hashtable();
connectionProperties.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_MANAGED);
connectionProperties.Add(MQC.USE_MQCSP_AUTHENTICATION_PROPERTY, true);
connectionProperties.Add(MQC.HOST_NAME_PROPERTY, hostName);
connectionProperties.Add(MQC.CHANNEL_PROPERTY, channel);
connectionProperties.Add(MQC.PORT_PROPERTY, portNumber);
connectionProperties.Add(MQC.CONNECT_OPTIONS_PROPERTY, MQC.MQCNO_RECONNECT_Q_MGR);
return connectionProperties;
Учитывая, что я новичок в IBM MQ, я заметил, что у меня есть свойство подключения MQC.MQCNO_RECONNECT_Q_MGR
. Будет ли это играть роль? Я стремлюсь знать и управлять, когда дела идут плохо, а не полагаться на то, что мы не совсем понимаем.