問題タブ [faulted]

1 つのClientBase<T>インスタンスが複数の WCF サービス呼び出しに使用されると、チャネルが障害状態になる可能性があります (つまり、サービスがダウンしている場合)。

サービスが再開されたときに、チャネルを自動的に修復したいと考えています。私が見つけた唯一の方法は、各メソッド呼び出しの前に次のコードを呼び出すことです。

これは正しいやり方ではないと感じました。誰かがより良いアイデアを得ましたか？

私の WCF クライアント クラスではFaulted()、リモート サービスが例外をスローしてチャネルに障害が発生した場合でも、少なくとも正常にシャットダウンできるように、イベントを処理しています。これが私のコードです：

したがって、私が期待するのは、クライアントがChannelTerminatedException手動でスローした を処理し、ユーザーなどにメッセージを送信できることです。代わりに、私の例外はSystem.ServiceModel.Diagnostics.CallbackException. いいよ。ただし、キャッチは次のとおりです。この CallbackException は ServiceModel ライブラリには存在せず、ジェネリックとして処理する以外に方法がないように見えますがException、単体テストには適していません。ここで一体何が起こっているのですか？どういうわけかそれを無効にして、最初に欲しかった例外をスローできますか?

WCFで問題が発生したときに何が起こるかを理解しようとしているだけです。PerSession の InstanceContextMode で宣言されたサービス コントラクトの実装があります...

呼び出しは次のように行われます。

1. 私のクライアントはサーバーを呼び出し、GetServerUTC() を呼び出してサーバーの現在の UTC 時刻を返します。これは一方向の呼び出しであり、サーバーはクライアントの準備ができたときにコールバックします (この場合、単純に現在の時刻を返すのは簡単です!)

2. サーバーはクライアントにコールバックし、クライアントのコールバック実装でテスト目的で例外をスローします。

3. これはクライアントで (テスト目的で) 処理されず、クライアントがクラッシュして終了します。

4. サーバー上で、ICommunicationObject の faulted イベント ハンドラーを処理します...

   obj.Faulted += 新しい EventHandler(EventService_Faulted);

質問...

• これにより、サーバー上の現在の接続のセッションが強制終了されますか。

• このメソッドで必要なこと、たとえばロギングなどを自由に行うことができると思いますが、セッションを終了するためにここで特定のことを行う必要がありますか、それとも WCF がこれを処理しますか?

ベスト プラクティスの観点から、コールバックが失敗した場合はどうすればよいですか? それは「あなたのクライアントで何かが起こった」という意味ですか？

さらに、私が処理する必要がある他の障害のあるハンドラーはありますか。

私はWCFについて多くのことを読んできましたが、何か問題が発生したときに何をすべきかについて漠然としているようです。現在、接続を管理し、サーバーへの接続が存在するかどうかに応じてユーザーアクションが発生するかどうかを判断するステートマシンをクライアントに実装しています-またはこれはやり過ぎです。

どんなヒントでも大歓迎です;）

私は自分の wcf サービスにこの例を使用しました: http://www.codeproject.com/KB/IP/WCFWPFChatRoot.aspx?msg=3713905#xx3713905xx

しかし、サーバーが停止すると、クライアントはそれを取得できません...

例では次のように処理しました。

しかし、ホストを停止するか、クラッシュした場合 (ALT + F4)、クライアントはそれを取得しません。接続状態はまだ「接続済み」です。

私は信頼できるセッションの非常に興味深い振る舞いに遭遇しました。netTcpバインディング+デュプレックスチャネル+信頼できるセッションを使用しています。

channel.faultedでリッスンしようとしているときに、セキュリティモードがトランスポートに設定されている場合、クライアントが切断されるとすぐにfaultedイベントが発生します。

ただし、バインディングのセキュリティモードを[なし]または[メッセージ]に設定すると、同じ状況で障害イベントが発生しなくなりました。最終的には、サーバー側でReciveTimeoutの半分に障害が発生します。これは、信頼できるセッションがその時点でハートビートメッセージを送信することを理解しています。

問題は、なぜwcfバインディングが時間どおりに失敗しないのかということです。

この場合の回避策は、接続を手動で「ping」できることです。

Web アプリから使用している WCF サービスがあります。使用しているクライアントは、Visual Studio の [サービス参照の追加] オプションを使用して生成されました。これは Web アプリであり、アプリの性質上、セッションは比較的短いものになる可能性が高いため、ユーザーがログインしたときにクライアントのインスタンスを作成し、セッションが終了するまでそれを保持することにしました。セッションが終了したときにそれを破棄します。

これは私の質問につながります.Faulted状態に入るクライアントのチャネルを処理する最善の方法を決定しようとしています. いくつかを検索した後、これを思いつきました：

ただし、これは機能しません。少なくとも私たちの場合、サービスがダウンしていても、Open実際にそれを使用して呼び出しを行うまで、クライアントは状態を表示し、その時点でFaulted状態に入ります。 .

したがって、これにより、他のことを行う必要があります。私たちが思いついた別のオプションは次のとおりです。

しかし、それはにおいがします。明らかに、新しいクライアントを使用し、呼び出しごとに破棄することで、これを回避できます。それは不必要に思えますが、それが正しい方法であれば、それが私たちが選ぶものだと思います. では、クライアントが障害状態にあるかどうかを判断し、それに対して何かを行う最善の方法は何でしょうか? 通話ごとに新しいクライアントを取得するだけでよいのでしょうか?

もう 1 つ注意してください。クライアントのインスタンス化と、このすべてのチェックと処理は、クライアントのラッパー クラスで行われます。意図したとおりにこれを行うと、アプリ自体に対して透過的になります。呼び出しを行い、それらからの例外を処理するために特別なコードは必要ありません。

やあ、

DuplexChannelFactoryを使用してWCFクライアントを作成しますが、これを行うと問題が発生します。

次の例外が発生します：

リモートオブジェクトへのプロキシであるため、タイプ'System.ServiceModel.ICommunicationObject'のインスタンスでフィールドを取得したりメソッドを呼び出したりすることはできません。

なんで？

チャネルに障害が発生していないかどうかを確認する必要があります。

編集1：

私は WCF で netTcpBinding を使用しています。サーバーに再接続できるように、クライアント側で切断されたとき、またはチャネルの状態が障害になったときを知りたいです。

アイデアは、チャネルイベントを使用してキープアライブを作成することです。Channel.Faulted イベントを使用して、サーバー側でクライアントが切断された/障害状態になったことを知ることができることを知っています。そうすれば、クライアントがサーバー上に持っていたサブスクリプションをすべて削除できます。ただし、サーバー側でクライアントに再接続できません。そして、それはまさに私がやりたいことです。

クライアントが例外をスローしている1つのWCFサービスを使用しています（例外：通信オブジェクトSystem.ServiceModel.Channels.ServiceChannelは、Faulted状態であるため、通信に使用できません）。以降のすべての呼び出しで同じ例外がスローされます。

私はインターネットでクライアントがclose（）/ Abort（）チャネルを必要としていることを読みました、これは問題を解決します。それは完全に正しいですか？

また、サービス開発者が提供するカスタマーサービスチャネルファクトリを使用しています。チャネルを作成すると、closeメソッドとabortメソッドが表示されません。では、クライアント側でカスタムサービスチャネルインスタンスを作成するときに、これらのcloseメソッドとabortメソッドを取得するにはどうすればよいですか？

通信オブジェクトSystem.ServiceModel.Channels.ServiceChannelは、Faulted状態であるため、通信に使用できません。

WindowsアプリケーションがwsDualHttpBindingを介してWindowsサービスとしてホストされているWCFと通信しようとすると、このエラーが発生します。WCFは、シリアルポートを介してデバイスと通信するために使用されます。WCFWindowsサービスを介してコマンドを頻繁に送信するために使用されるWindowsアプリケーション。

スタックトレースは次のとおりです。

スタックトレース：System.ServiceModel.Channels.CommunicationObject.ThrowIfDisposedOrNotOpen（）at System.ServiceModel.Channels.ServiceChannel.Call（String action、Boolean oneway、ProxyOperationRuntime operation、Object [] ins、Object [] outs、TimeSpan timeout）at System .ServiceModel.Channels.ServiceChannelProxy.InvokeService（IMethodCallMessage methodCall、ProxyOperationRuntime operation）at System.ServiceModel.Channels.ServiceChannelProxy.Invoke（IMessage message）

[0]で再スローされた例外：System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage（IMessage reqMsg、IMessage retMsg）at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke（MessageData＆msgData、Int32 type）atGridSplitter.CommandServiceReference。 ICommandService.SendToMultipleChannel（String [] channel、Int32 [] [] locid、String cmd、Int32 cmdData）at GridSplitter.CommandServiceReference.CommandServiceClient.SendToMultipleChannel（String [] channel、Int32 [] [] locid、String cmd、Int32 cmdData）at GridSplitter.MainWindow.bwChkAndSendRedeploy_DoWork（オブジェクト送信者、DoWorkEventArgs e）：11/9/2012 11:05:58 AM

1. なぜサービスが故障状態になっているのか理解できませんでした。
2. この例外をキャッチして、パッチワークを実行する必要がありますか（推奨されている場合）？
3. TCPバインディングは、この例外を回避/削除するのに役立ちますか？