3

Windowsサービス内でWebAPIセルフホストを使用していますが、問題が発生し、数時間グーグルした後、妥当な答えが見つかりませんでした。

APIコントローラーの1つは、大量のデータストリームを提供します(実際にはそれほど大きくはなく、数十MB)。データの生成には時間がかかるため、 TransferMode.StreamedResponseを使用して、クライアントが応答を待機する時間を最小限に抑えることにしました。また、主に次の回答に基づいて、CompressHandlerカスタムCompressedContent(から派生)を追加しました。HttpContent

コントローラはのインスタンスを返しますIDataReader。これは、カスタムフォーマッタによってシリアル化され、最後に前述の内部CompressedContentで圧縮されます。渡されるデータ全体がストリーミングされるため、クライアントがデータを受信して​​いる間、サーバー側のデータリーダーがデータベースから行を読み取っている可能性があります。クライアントがうまく機能しているときは、すべてが正常に機能します。

この問題は、データが基になるネットワークストリームにシリアル化されている間に、クライアントが接続を切断した場合に発生します。デリゲートIsFaulted内(リンクから)のタスクを監視し、基盤となるネットワークを破棄しようとしました。残念ながら、コントロールがコードを離れるときに、(指定されたネットワーク名は使用できなくなりました)がまだスローされています。スタックトレースから、Web Apiが基盤となるネットワークストリーム(httpチャネル?)を閉じ(終了)しようとすると、例外がスローされたように見えます。観察されない例外で発生するように、Windowsサービス全体がダウンします。ContinueWithCompressedContentStreamCommunicationException

Windowsサービスの回復オプションを設定することで問題を軽減しましたが、この障害をコードで処理できるかどうかを知りたいです。

IErrorHandlerこの種のエラーを防ぐために、Web APIセルフホスティングサービスモード内で(おそらく)カスタムエラーハンドラーをセットアップする方法はありますか?

私はベータ版を使用しています。RCでこのエラーを再現しようとしますが、この種のエラーハンドラーの設定が何らかの形で変わるのではないかと疑っています。

4

1 に答える 1

3

同じ問題がありました。私はMSに修正を送信することができ、MSはこれを修正するナイトリービルドをリリースしました。彼らは、修正をRTMにバックポートすることを検討しています。ここでプルリリースを見ることができます:http://aspnetwebstack.codeplex.com/SourceControl/network/forks/rdean79/issue284/contribution/3329

于 2012-10-03T13:40:27.973 に答える