これが少し基本的なことのように思われる場合はお詫び申し上げますが、WCFは初めてであり、プロセス間通信全般についても初めてです。
セットアップの詳細
Windowsサービスとして実行されるアプリケーションの一部であるWCF「サーバー」でNetNamedPipeBindingを使用しています。
DuplexChannelFactoryによって作成されたチャネルを使用して、WCFサーバーと通信する2つのクライアントがあります。1つはASP.NetMVC3 Webアプリケーションで、ページ要求ごとにチャネルを作成します(そしてチャネルを閉じます**)。もう1つはWPFアプリケーションです(サービスの一種の監視コンソール/診断ツールとして使用されます)。
多くの人がWebアプリケーションにアクセスし、すべてが正常に実行されます(多くの場合、1週間以上)が、WCF「サーバー」内で何かが壊れ、クライアントが「通信オブジェクト、System.ServiceModel.Channels」という例外を報告し始めることがあります。 ServiceChannelは、チャネルプロキシを作成しようとするたびに、「障害状態にあるため、通信に使用できません」。
サーバーに「障害」が発生すると、接続しようとするたびにそのエラーが発生します。コンソールアプリケーションの新しいインスタンスでさえ、それを報告します。これは、それが「クライアント」側の問題ではないと私に信じさせます。
**注:チャンネルはページリクエストごとに閉じられると思います。これはMVCコントローラーのメンバーとしてインスタンス化されますが、私の知る限り、これは範囲外であり、リクエストの最後に破棄されます。おそらく私は間違っていますか?
質問):
どこを見ればよいか、そしてテスト環境でこの問題をどのように再現できるかについて、誰か提案がありますか。
このようなことを完全に排除することはできますか?または、名前付きパイプサービスに数分ごとに接続し、失敗した場合にサービスを再起動しようとするスレッドを「サーバー」内に配置する必要がありますか?
追加情報
名前付きパイプでリクエストをリッスンするために(WCF「サーバー」で)使用しているコードを含めると役立つ場合があります
host = new ServiceHost(
this,
new Uri[] {
new Uri("net.pipe://localhost")
}
);
host.AddServiceEndpoint(
typeof(IStationDirectory),
new NetNamedPipeBinding(),
"StationDirectory"
);
host.Open();
/* Some logging code here */
Thread.Sleep(Timeout.Infinite);
さらに質問を
私が正しく理解していると仮定すると、各NamedPipeの「チャネル」は事実上TCP接続と同じものです(各クライアント/サーバーペアに固有)。新しいクライアントでチャネル障害エラーが発生し続ける場合は、クライアントによって作成されているすべての新しいチャネルが最初から何らかの形で壊れている可能性があります。これは、障害がServiceHost内のどこかにあることを意味しますか?ここで失敗したイベントをホストをキャッチすることに何か利点はありますか?
決議の更新(2013)
私がこの質問をしてから非常に長い時間が経っていることを私は知っています-しかし、私はここSOで私の歴史の中でそれに気づきました、そして私はニックが頭に釘を打ったことを付け加えるべきだと思いました。問題を引き起こしたのはメッセージのペイロードサイズだったと思います。メッセージには、それぞれが前のレポートにリンクされている「レポート」オブジェクトのリストが含まれていました。時間の経過とともに、このリストは大きくなります。古いレポートを削除し、WCFメッセージを多かれ少なかれ固定サイズに保つことで、障害を停止しました。この数年間、アプリケーションは非常に確実に実行されています。