16

Microsoft のサンプルであるDesign Patterns: List-Based Publish-Subscribe にほぼ従っている WCF アプリケーションで pub-sub モデルを使用しています。

このサービスは と の概念を提供しsubscribe()ますunsubscribe()が、クライアントが停止したりチャネルに障害が発生した場合の状況でクリーンアップを処理するためのベスト プラクティスは何ですか? 現在、クライアントがサブスクライブすると、現在InstanceContextのClosedおよびFaultedイベント (サービス ユーザーは PerSession インスタンス コンテキスト モードと netTcpBinding)にハンドラーをアタッチします。

_communicationObject = OperationContext.Current.InstanceContext;
_communicationObject.Closed += OnClientLost;
_communicationObject.Faulted += OnClientLost;

OnClientLostただし、ハンドラーはクライアントのサブスクライブを解除するだけです。

  1. 上記は良い方法であり、クライアントが二重通信を切断したときにすべての状況を捉えるのに十分なだけの堅牢性を備えていますか? それとも、サービスがクライアントとの通信を試みた時点で発生した例外を処理し、クリーンアップを処理する必要がありますか?
  2. クライアント コールバック ハンドラのサブスクライブを解除するだけでなく、特に障害が発生した場合にさらにクリーンアップを実行する必要がありますか?

この質問は同様の質問を提起しますが、最終的には、サブスクライブおよび/またはサブスクライブ解除を呼び出すクライアント以外のケースに対する回答を提供しません

ありがとう

4

2 に答える 2

8

コールバックチャネルのClosedイベントとFaultedイベントにハンドラーをアタッチし、サーバーによってコールバックが呼び出される直前の時点でクライアントを強制終了するテストを行いました。各試行で、サーバーがコールバックを呼び出そうとする前に、Closed/Faultedイベントが即座に発生しました。それでも、別のスレッドがコールバックに入るときにクライアントチャネルが破棄される可能性があるため、コールバック呼び出しはtry-catchブロックにラップされています。

必要な唯一のクリーンアップは、コールバックチャネルへの参照を削除することでした。残りはWCFとガベージコレクターが行います。

于 2011-01-20T16:28:06.727 に答える
2

これらのイベントを処理すると、購読者のリストが同期された状態に保たれます。それは確かに十分に堅牢です。メッセージの送信中にクライアントがドロップした場合、これらのイベントが発生する前に例外が発生する可能性があるため、イベントをクリーンアップできるようにそれらを無視する準備をしてください。

サブスクライバー リストからクライアントを削除する場合を除いて、追加のクリーンアップはアプリケーションに完全に依存します (つまり、クライアントが接続したときに取得したリソースを解放します)。必要なその他のクリーンアップについては知りません。

于 2011-01-13T22:17:47.307 に答える