0

私 (およびインターネット上の他の多くの人々) は、.NET Remoting を使用するときにクライアント側の TcpChannel タイムアウトを構成できないため (適切な修正を提案しないでください。文字通りすべてを試しましたが、WCF の提案はありません)。構成可能なクライアント側のタイムアウトを作成するための適切な回避策のように思われるものを思いつきました。それぞれの Remoting 呼び出しを個別のタイマー スレッドを介してフィードし、呼び出しがタイムアウトするか、例外をスローした場合、スレッドを強制終了して、サーバーがダウンしていると見なすことができます。

しかし、別の同僚がこれを実行したところ、.NET のネイティブ マシン コードでデッドロックが発生する可能性があると断言されました。この投稿のように、このタイプの手法がインターネット上で機能している他の例を読んだことがあります。何かを送信または受信している最中にスレッドが中止された場合は問題になる可能性がありますが、応答を待っているだけの場合はそうではありません。

4

1 に答える 1

0

ダンは回答を投稿せず、コメントしただけなので、私はこの回答を彼に帰します. タイムアウトが発生した場合にスレッドの実行が続行されないように予防措置を講じている限り、タイムアウトを管理するこの方法は問題ないようです。また、自分が何をしているのかわからない限り、Thread.Abort を使用しないことをお勧めします。

于 2012-10-17T15:16:13.383 に答える