Соединения для каждого потока, поэтому, если вы пытаетесь создать новое соединение, пока предыдущий объект QMgr еще создается, вы получите это. Если вы закроете предыдущее соединение и уничтожите объект перед созданием нового объекта, все будет в порядке. Поскольку очереди и другие объекты WMQ зависят от дескриптора соединения, их также необходимо будет уничтожить, а затем заново создать после установления нового соединения.
Конечно, есть несколько других объяснений этого поведения, но они гораздо менее вероятны. Например, возможно, что выход канала или (в WMQ v7) конфигурация может ограничивать количество одновременных соединений с данного IP-адреса. Когда соединение разорвано, а не закрыто, агент канала, удерживающий соединение на стороне QMgr, должен установить тайм-аут, прежде чем QMgr увидит, что соединение закрыто. Если ограничение соединения установлено, эти «призрачные» соединения уменьшают доступный пул. Но, как я уже сказал, это гораздо реже, чем программы, не очищающие старые объекты перед попыткой повторного подключения.
Существует также вероятность того, что это ошибка. Чтобы уменьшить эту возможность и по ряду других причин, таких как WMQ v6, выходящий из строя в следующем году, я бы рекомендовал использовать WMQ v7.0.1.2 для этого проекта как на стороне клиента, так и на стороне сервера. В общем, вы можете использовать клиент v7.0.1.2 с сервером v6.0.x, если вы придерживаетесь функциональности v6. Помимо прочего, код .Net лучше интегрирован в v7, а пакеты поддержки Cat-3 теперь включены в базовый установочный носитель, а не в отдельную загрузку.