3

次のコードを使用してMQQueueおよびMQQueueManagerから切断しています。

Queue.Close（）;
log.Info（ "Queue IsOpen：" + Queue.IsOpen.ToString（））;
キュー=null;

QueueManager.Disconnect（）;
QueueManager.Close（）;
log.Info（ "QM IsOpen：" + QueueManager.IsOpen.ToString（））;
log.Info（ "QM IsConnected：" + QueueManager.IsConnected.ToString（））;
QueueManager = null;

そして、私はこれについて次のログエントリを取得します：

キューIsOpen：false
QM IsOpen：false
QM IsConnected：false

しかし、コマンドプロンプトからnetstat -nコマンドを実行すると、数時間後にMQサーバーへの接続の長いリストが表示され、それらの接続の状態はCLOSE_WAITになります。

TCP接続が完全に閉じられない理由はありますか？コードからそれらを殺すことができる方法はありますか？現在、開いている接続をクリーンアップするクライアントアプリを再起動する必要があります。

WebSphere MQのバージョンは6.0.2.6であり、.NETライブラリーはMQ7のものです。

4

1 に答える 1

1

移行ガイドを見ると、WebSphere MQクライアントをバージョン6.0からバージョン7.0にアップグレードするというセクションがあり、考えられる説明が示されています。v7の時点で、TCPチューニングはクライアント構成ファイルに保存されていると記載されています。したがって、WindowsレジストリでTCPキープアライブを有効にしている場合、v7クライアントはそれを無視します。ファイルの形式と場所は、WebSphereMQクライアント構成ファイルに記述されています。

もちろん、これが問題になるには、ソケットリークが必要です。使用しているWMQV7クライアントのバージョンについては言及していませんが、Fix Pack READMEファイルには、ソケットリーク、切断後のクリーンアップの失敗などに関連する多数のAPARが示されています。これらのいずれもC＃または.Netに直接言及していませんが、接続/切断の問題に関しては、アップグレードする価値があるほど十分な問題があります。

したがって、最初の最も簡単な修正は、TCPキープアライブをクライアント構成ファイルに追加して、それが役立つかどうかを確認することです。そこにいる間も接続の共有を無効にします。それは要因ではないはずですが、それでもソケットをリークすることは想定されていません。傷つけることはできません。次に、Fix Pack 7.0.1.2（この記事の執筆時点で最新）を適用し、それで問題が解決するかどうかを確認します。その後、PMRの時間です。お役に立てば幸いです。

于 2010-06-22T01:00:29.740 に答える