5

私のアプリケーションには、すべてのリクエストを中央の ControllerServlet にマップする独自のフレームワークがあります (派手なものではなく、ほとんどすべてのフレームワークの基本機能を備えています)。Publisher-Subscriber メッセージング交換機能を実装する必要があり、Servlet 3.0 の非同期メソッドを使用することにしました。

現在は asyncSupported として設定されていませんControllerServlet。AuthenticationFilterすべての非同期処理に 2 番目の CotrollerServlet を実装するか、既存の ControllerServlet をasyncSupported=true(非同期処理を必要としない要求があっても) として宣言することができます。

...アプリケーションが非同期機能を使用するには、リクエスト処理チェーン全体に、アノテーションまたはデプロイメント記述子でこの属性を設定する必要があります... - source

ここから、AuthenticationFilterasを宣言する必要があることを理解していますasyncSupported=true(また、非同期が必要ない場合もあります)。

asyncSupported=true非同期処理を必要としないリクエストもマップしますが、サーブレットとフィルターを宣言することの欠点はありますか? スケーラビリティの問題はありますか?

4

1 に答える 1

1

Java Servlet 3.0 仕様の2.3.3.3 非同期処理の章には、ヒントが含まれています。

同期サーブレットから非同期サーブレットへのディスパッチは違法です。ただし、IllegalStateException をスローする決定は、アプリケーションが startAsync を呼び出す時点まで異なります。これにより、サーブレットは同期サーブレットまたは非同期サーブレットとして機能できます。

直接的には述べられていませんが、この文は、1 つのサーブレットのそのような二重の同期/非同期の性質は、JLS の作成者に関する限り、珍しいことではないと私に信じさせます。

一方、コンテナのドキュメント/ソース コードを参照してください。JLS の観点から合法であるからといって、コンテナが実際に使用されていない場合にパフォーマンスに悪影響を与える巧妙な最適化を行っていないわけでAsyncContextはありません。そうではなく、すべてのサーブレットがいずれかのモードで単純に機能する場合、文書化を除いて、この属性の目的は何でしょうか?

于 2012-08-19T16:34:19.793 に答える