Servlet 3.1 フィーチャーの機能

WebSphere® Application Server traditional は、Servlet 3.1 仕様をサポートしています。ここで取り上げた機能の説明や解説を考慮してください。

新フィーチャー 新フィーチャー:
本製品は、Servlet 3.1 の機能をサポートしています。

すべての機能に関する記述は Java Servlet 仕様で提供されており、製品資料にはすべてが記載されているわけではありません。 Servlet 3.1 機能に関する追加の考慮事項は、以下のとおりです。

newfeat

非同期入出力

非ブロッキング読み取りが開始されると、残りの要求存続期間中、リソースは API を呼び出すことができないことを指定する Servlet 3.1 フィーチャー。この読み取りは、結果としてブロッキング読み取りになることがあります。 例えば、読み取りリスナーがリソースによって設定された後の POST 要求の場合、その後に getParameter() および getPart() API を呼び出すと、IllegalStateException が発生します。

非同期サーブレットを扱う場合は、AsyncContext.setTimeout API を使用してタイムアウトを設定してください。設定しないと、コンテナーのデフォルト値 (例えば 30 秒) が使用されます。 ServletRequest を使用して非同期が開始されるたびに、タイムアウトがリセットされます。 StartAsync API が呼び出され、最後の非同期が開始された後のタイムアウト期間内に AsyncContext.complete API が呼び出されないと、有効期限が切れます。提供されている非同期入出力サポートを使用する場合は、非同期入出力の完了もできるように、、AsyncContext.setTimeout API を使用してタイムアウト値を設定します。完了は、環境やネットワーク速度などの他の外部要因に依存します。

アップグレード処理

アップグレード処理は、非ブロッキング読み取り/書き込み機能を備えた Servlet 3.1 フィーチャーです。 読み取り操作または書き込み操作が非同期の場合、操作が完了するのをサーバーが待機する時間に制限はありません。 server.xml ファイルで Web コンテナー・カスタム・プロパティー (upgradereadtimeoutupgradewritetimeout など) を使用して、タイムアウトを設定できます。 タイムアウトが 5 秒の次の例を参照してください。
<webContainer upgradeReadTimeout="5000" />
<webContainer upgradeWriteTimeout="5000" />

要求が非同期サーブレットによって処理されている場合、Servlet 3.1 のアップグレード・フィーチャーを使用して要求をアップグレードしてはなりません。

Servlet 3.1 のアップグレード・フィーチャーをサポートするアプリケーションでは、クライアントとアップグレードをホストするアプリケーションとの間で、要求での接続が開いたままである必要があります。アップグレード処理の完了時にアプリケーションがそのハンドラーや他のリソース (ReadListener や WriteListener など) から WebConnection close () を開始しなければ、TCP 接続はサーバーが再始動されるまで開いたままになります。

Servlet 3.1 フィーチャーの UpgradeHandler および ReadListener を使用する場合、ReadListener.onAllDataRead メソッドが呼び出されるのは、アップグレードされるアプリケーションをホストしているサーバーへの接続をクライアントが閉じた場合のみです。onReadListener.onAllDataRead の Javadoc は、次のメッセージを戻します。
Invoked when all data for the current request is read.
アップグレードの場合、アップグレードされたデータは、HTTP 要求本体のデータのように区切られていないため、サーバーはデータの末尾を認識できません。クライアント接続が閉じられたタイミング以外に、データの末尾を判別する方法はありません。

フォーム・ベース認証

認証に成功すると、クライアントは、元の要求のリソースにリダイレクトされます。Servlet 3.1 仕様では、「リダイレクトされた要求の HTTP メソッドの予測可能性を向上させるために、コンテナーは 303 (SC_SEE_OTHER) 状況コードを使用してリダイレクトする必要がある (ただし、HTTP 1.0 ユーザー・エージェントとの相互運用性が必要な場合は例外で、302 状況コードを使用する必要がある)」ということが規定されています。Servlet 3.1 フィーチャーは、HTTP 1.0 ユーザー・エージェントとの相互運用性を維持するため、常に 302 状況コードを使用します。セキュリティーのための Servlet 3.1 の構成について詳しくは、『Servlet 3.1 のための構成』のトピックを参照してください。

大きなポスト・データ

ServletRequest.getContentLengthLong() API を追加するには、Integer.MAX_VALUE より長くて 1 バイトの配列やストリングには完全には収まらない長さのポスト・データの受信のサポートが必要となります。

この追加は、ストリングまたは byte[] でコンテンツを返す API を使用しているポスト・データ・コンテンツを取得する場合に影響があります。例えば、パラメーターにアクセスするための javax.servlet.ServletRequest メソッドは、以下のとおりです。
String    getParamter(String name)
String[]  getParameterValues()
Map<String,String> getParameterMap()

複数のパラメーターが含まれていて、それぞれを合わせると長さが Integer.MAX_VALUE より大きくなるポスト・データを送信することが可能です。 ただし、それぞれの個別のパラメーター名とパラメーター値の長さが Integer.MAX_VALUE 未満でなければなりません。

大容量のポスト・データを送信する場合、以下の追加の考慮事項を検討してください。
  • 長さが Integer.MAX-VALUE 未満のチャンクでポスト・データを送信する必要があります。
  • パラメーターやパートなど、Web コンテナーによって処理されるポスト・データは、処理の開始前に完全に読み取る必要があります。大きいポスト・データの場合、大量のメモリー所要量が必要になることがあります。これは、Web コンテナー処理を成功させるために、ポスト・データの倍のサイズのメモリーが必要になることがあるためです。

トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cweb_servlet31
ファイル名:cweb_servlet31.html