4

私は、私たちが目にしているいくつかの奇妙なチャネル障害の異常を診断するのに役立つことを願って、ラボの変更を出荷することに取り組んでいます. DuplexChannelFactory を使用していくつかの Windows サービスに接続するテスト アプリケーションがあり、何らかの理由でこのテスト アプリケーションのチャネルにかなりの障害が発生しているようです。そこにいくつかの再試行ロジックを実装する計画がありますが、なぜそれらが失敗しているのかを正確に理解することは素晴らしいことです.

チャネル ファクトリとプロキシ オブジェクトはすべて多くのインターフェイスを実装していることを知っており、リフレクターを使用してそれらのいくつかをクロールしましたが、探しているようなものは見つかりませんでした。障害の原因に関する情報を取得するために、障害が発生した後にこれらのオブジェクトにクエリを実行する方法はありますか?

編集: 構成は非常に基本的なものです。バインディングはデフォルトで構築された NetTcpBinding のみであり、サービスの実装には が[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Reentrant)]あり、サービス コントラクトの操作には特別な属性はありません。ただし、この特定のケースを診断するのではなく、チャネル障害を診断する一般的な手法について詳しく質問しています。構成の詳細がそれに大きな影響を与えるとは思いません。どちらかといえば、構成の詳細は、上記の診断によって返されるものですよね?

4

4 に答える 4

5

Ladislav と Shiraz の回答はすべて良好で、+1 を付けました。

私が付け加えることができるのは、通常、障害のあるチャネルは、サーバーで未処理の例外が発生した結果であるということだけです。その場合、WCF はサーバーに根本的な問題があると判断し、チャネルを使用できないように障害を起こします。

正しいアプローチ - デフォルトで無料で提供されるべきだったと私は信じています - サービスが例外をキャッチして FaultException を作成し、それを返すことです (このフォームの例を見てください http://www.c-sharpcorner.com/UploadFile /ankithakur/ExceptionHandlingWCF12282007072617AM/ExceptionHandlingWCF.aspx )

WCF がデフォルトとして作成しない理由は、コントラクトと WSDL が変更されるため、クライアントは更新された WSDL を取得する必要があるためです。

したがって、私があなただったら、例外をキャッチしてログに記録し、エラー例外を返します。これにより、問題が何であるかがわかり、チャネルにエラーが発生しなくなります。

于 2010-10-09T09:26:39.870 に答える
4

まず、このテストアプリケーション、または他のクライアントが使用する特定のサービスです。

問題を引き起こしているのはテストクライアントであると想定します。2つの問題が考えられます。

  • プロキシを閉じないため、サーバーへの最大接続数に達します。
  • 失敗した状態のときにプロキシを中止しない。
于 2010-10-08T18:12:08.837 に答える
3

お探しの診断ツールはWCF Tracingと呼ばれます。通常、チャネルに障害が発生した理由が示されます。クライアントとサーバーの両方で構成し、SvcTraceViewer.exeを使用して収集されたトレースを参照できます。

于 2010-10-08T20:07:33.070 に答える
0

ICommunicationObject.OnFauledに夢中になりましたか

于 2010-10-10T06:07:13.180 に答える