2012-03-13 9 views
2

数回I生産を通して、メッセージを送信するに青色のうちネット(C位、4.0)アプリケーションから次のエラーを受信した:IBMのWebSphere XMS.Net CWSMQ0082Eエラー

CWSMQ0082E: Failed to send to CompCode: 2, Reason: 2009. A problem was encountered whilst sending a message. See the linked exception for more information.

もちろん、LinkedException(なぜInnerException IBMを使用していないのですか?)は空です。つまり、情報がありません。私が使用している

コード(非常に簡単):

var m = _session.CreateBytesMessage(); 
m.WriteBytes(mybytearray); 

m.JMSReplyTo = myreplytoqueue; 
m.SetIntProperty(XMSC.JMS_IBM_MSGTYPE, MQC.MQMT_DATAGRAM); 

m.SetIntProperty(XMSC.JMS_IBM_REPORT_COA, MQC.MQRO_COD); 
m.SetIntProperty(XMSC.JMS_IBM_REPORT_COD, MQC.MQRO_COA); 

myproducer.Send(m, DeliveryMode.Persistent, mypriority, myttl); 

(Offtopic:。私はプロパティを設定するSetIntProperty方法を憎むどちらが<虚辞が>を削除し、そのアイデアを思い付いたことを見て年齢を取ります? )。

例外は.Sendメソッドでスローされます。私はXMS.Net(IA9H/2.0.0.7)を使用しています。 only Google resultそのturns upは別の理由コードを持っていることが判明しています(それが同じであっても、私が正しく理解すれば私のバージョンで修正する必要があります)。これはランダムに発生します(ただし、メッセージが送受信されてからしばらくしているように見えます)、これを再現する方法はありません。

私はab-so-lute-ly いいえアイデアを持っています。これはサーバー側によって引き起こされたものですか?それはXMS.netや基礎を成すIBM WebSphere MQインフラストラクチャによって引き起こされますか?

私はは似が0よりも高いか、「真」/「はい」に任意の値にSHARECNVを設定するために示唆されているが、the documentationが明示的にデフォルトでも10です私に語ったように見えることを発見し、一部の結果。私はこれが原因であるかどうか分かりませんので、別の値に変更するとショットガンのように感じられます。

誰でもこれを解決する方法についての任意のアイデアですか?私はもちろん例外を捕まえることができ、すべて(チャネル、セッション、何でも)引き裂き再開することができますが、それは単なる醜いIMHOです。

答えて

4

2009リターンコードは、「Connection Broken」を意味します。基本的に、基礎となるTCPソケットはなくなり、クライアントはAPI呼び出し時にそれについて調べます。ハートビートとキープアライブを使用してチャネルをチューニングすることで、WMQがソケットを有効に保ちます。しかし、ソケットが基盤となるインフラストラクチャによってタイムアウトした場合、WMQが行うことはできません。たとえば、ファイアウォールやロードバランサは、アイドル状態の接続を検出して切断するように設定されている場合があります。

最新バージョンのWMQクライアントでは、reconnect transparentlyが試行されます。これが発生すると、アプリケーションはちょっとブロックします。

自動再接続を使用しないと、唯一の解決策は実際に接続を再構築することです。新しい接続ハンドルを取得するので、すべてのオブジェクトハンドルも再構築する必要があります。

ここに記載されているチューニング機能の多くは、client configuration file(v7.0以上のクライアントで利用可能)を通じて利用できます。特に、そのファイルのTCP stanzaはキープアライブを有効にします。 (TCP仕様では、キープアライブが提供されている場合は、デフォルトで無効にする必要があることを示しています)。QMgrにはキープアライブを含むa similar ini fileコンフィグレーションスタンがあります。最新のWMQクライアントは、必要に応じてSupportPac MQC71として入手できます。

+0

こんにちは、ご回答いただきありがとうございます。私はこの質問を投稿した後、私のクライアントを7.1.0.0にアップグレードし、オートリコネクト機能を使って試しました。 MQサーバのバージョンは6.x(正確にはわからない)であり、自動接続が動作するためには、サーバのバージョンが7.0.1である必要があります。私は「相手側」を支配していないので、私はこれについて何もできません。私は恐れています。 私があなたが提案した他の提案を調べます。 – RobIII

+0

ああ、ところで、すべてのMQオブジェクト(接続、セッション、プロデューサ/コンシューマなど)を再構築するのは地獄です。私は、これらのオブジェクト(または、少なくとも、その通信部分)を使用して、全体的な(Windows NT)サービスを解体し、「再起動」することを検討しています。 .. – RobIII

+0

それは少し醜いと思うが、あなたが言うように、それは速くて汚いが効果的で安全です。 V6は9月末に廃止されたので、V7.x QMgrをすぐに使えるようになります。これがあなたのWMQ管理チームのニュースであれば、私にオフラインで連絡してください。彼らにEOS発表へのリンクを与えて、移行について彼らに話すことができます。 v7.1のセキュリティ機能は、v7.0を完全にスキップできるほど魅力的です。 –

4

主な例外がエラーを示すのに十分な場合、内部例外はnullになります。あなたのケースでは、MQ理由コード2009です。これは、キューマネージャへの接続が壊れていることを意味します。何らかの理由で、アプリケーションとキュー・マネージャーが通信していたソケットが閉じられました。ソケットを閉じる理由は、ネットワークブリップになる可能性があります。

上記のT.Robの提案に加えて、問題をさらに理解するためにXMSとキューマネージャのトレースを実行することもできます。 XMS InfoCenterのトラブルシューティングの章を参照してください。

HTH

関連する問題