0

クリスマス休暇の最後の数日間、IHttpAsyncHandlerの実装をIRequiresSessionStateとともに使用して、ASP.NETアプリケーションを介してリモート共有上のXMLファイルを読み取ろうとすると、UnathorizedAccessExceptionに苦労していました。

多くの頭痛の種の後で、ハンドラーの外側のコードが問題なく機能したと結論付けた後(アクセス許可を参照)、スレッドの問題である可能性があると考えたので、IHttpAsyncHandlerをIHttpHandlerに変更すると、問題は解消されます。

ここで私を悩ませているのは、テストの目的で、IHttpAsyncHandler実装の場合は実際には使用しなかったということです(したがって、BeginProcessRequestとEndProcessRequestは使用せず、sync。バージョンのProcessRequestのみを使用しました。

誰かが目前の問題を説明しようとすることができますか?

ハンドラーを非同期で使用することにはいくつかの有益な問題があります。アプリケーションの後半で配信される値を事前にキャッシュできるためですが、それを機能させるには、IHttpAsyncHandlerを実装するときにのみ現れると思われるセキュリティの問題をパスする必要があります。 。

よろしくお願いします-そして幸せな休日:-)

4

1 に答える 1

1

ASP.NET インフラストラクチャは、非同期ハンドラーを別の方法で呼び出します (impl が本当に非同期であるかどうかに関係なく)。ネットワーク リソースへのアクセスに偽装を使用していた可能性はありますか? 私の推測では、必要な WindowsIdentity が、実際に要求を処理したスレッドプール スレッドに流れていなかったと思います (偽装 + 非同期ハンドラーを使用したことはありませんが、過去に他のスレッド状態フローの問題に悩まされていました)。

とにかく、真の非同期ハンドラーを正しく実装するにはコストがかかります。他の多くの非同期インフラストラクチャ (非同期ファイル i/o、非同期 DB クライアントなど) の上に構築していない限り、それは何の役にも立ちません (実際、最良の場合でも、非同期ハンドラーは raw を傷つけます)。パフォーマンス)。パフォーマンスのニーズが、非同期ハンドラーの余分な手間とオーバーヘッドを本当に正当化するかどうかを確認します (たとえば、プロセス内のスレッドよりも多くの同時要求を処理する必要があるなど)。

于 2009-12-23T03:52:26.857 に答える