Webアプリケーションのリロード機能での新規リクエストの実行待ちと，同時実行スレッド数制御との関係について説明します。なお，同時実行スレッド数の制御については，マニュアル「アプリケーションサーバ 機能解説 基本・開発編(Webコンテナ)」の「2.15　同時実行スレッド数の制御の概要」を参照してください。

(a)　Webアプリケーション単位，またはURLグループ単位の同時実行スレッド数制御を使用する場合

リロード機能での新規リクエストの実行待ちは，Webアプリケーション単位，またはURLグループ単位の同時実行スレッド数制御の実行待ちキューとは，別に制御されます。

• Webアプリケーション単位，またはURLグループ単位の同時実行スレッド数制御が設定されている場合
  Webアプリケーション単位，またはURLグループ単位の同時実行スレッド数制御が設定されているWebアプリケーションをリロードする場合，リロード機能での新規リクエストの実行待ちは次のように制御されます。
  
  • リロード機能で実行待ちとなった新規リクエストは，Webアプリケーション単位，またはURLグループ単位の実行待ちキューに登録されません。それらの実行待ちキューのサイズの上限に関係なく，実行待ちとなります。
  • Webアプリケーション単位，またはURLグループ単位の実行待ちキューに登録されたリクエストがある場合は，それらの実行待ちキューに登録されたリクエストの処理がすべて完了してから，リロードが開始されます。
  • リロード処理完了後，リロード機能で実行待ちとなった新規リクエストの処理が開始されますが，同時実行スレッド数を超えたリクエストは，Webアプリケーション単位，またはURLグループ単位の実行待ちキューに登録されます。それらの実行待ちキューのサイズの上限を超えたリクエストは，ステータスコード503（Service Unavailable）のエラーを返します。
• Webアプリケーション単位の同時実行スレッド数制御が設定されていない場合
  Webアプリケーション単位の同時実行スレッド数制御が設定されていないWebアプリケーションをリロードする場合，リロード機能での新規リクエストの実行待ちは次のように制御されます。
  
  • リロード機能で実行待ちとなった新規リクエストは，デフォルトの実行待ちキューに登録されません。デフォルトの実行待ちキューサイズの上限に関係なく，実行待ちとなります。
  • デフォルトの実行待ちキューに登録されたリクエストがある場合は，その実行待ちキューに登録されたリクエストの処理がすべて完了してから，リロードが開始されます。
  • リロード処理完了後，リロード機能で実行待ちとなった新規リクエストの処理が開始されますが，同時実行スレッド数を超えたリクエストは，デフォルトの実行待ちキューに登録されます。デフォルトの実行待ちキューのサイズの上限を超えたリクエストは，ステータスコード503（Service Unavailable）のエラーを返します。

(b)　Webコンテナ単位の同時実行スレッド数制御を設定する場合

Webコンテナ単位の同時実行スレッド数制御を設定している場合，リロード処理開始後に，Webコンテナ単位の同時実行スレッド数制御で実行できることになった，新規リクエストの処理スレッドが実行待ちとなります。

このため，リロード機能で実行待ちとなった新規リクエスト数がWebコンテナ単位の最大同時実行スレッド数まで達した場合，リロード処理を開始したWebアプリケーション以外のWebアプリケーションへのリクエストも，Webコンテナ単位の同時実行スレッド数制御機能によって実行待ちとなります。

処理中のリクエストの処理が完了しない場合には，cjreloadappコマンドで-tオプションを指定することで，処理中のリクエストを強制的に終了させて，リロード処理を開始できます。ただし，処理中のリクエストを強制的に終了できるのは，J2EEアプリケーション実行時間の監視機能のメソッドタイムアウトの適用対象メソッドだけです。また，メソッドタイムアウトの発生後にメソッドキャンセルが動作するように設定している場合は，タイムアウトの発生によって処理中のリクエストがキャンセルされて，リロードを開始できます。

J2EEアプリケーション実行時間の監視の詳細については，マニュアル「アプリケーションサーバ 機能解説 運用／監視／連携編」の「5.3　J2EEアプリケーションの実行時間の監視とキャンセル」を参照してください。J2EEアプリケーション実行時間の監視の設定については，「13.8.12　J2EEアプリケーションの更新検知とリロードの設定」を参照してください。

(a)　EJBアプリケーションの場合

EJBアプリケーションをリロードする場合について説明します。

構成ファイル更新用インターバルを経過すると，J2EEサーバは，処理中のリクエストの処理が完了するのを待ってリロード処理を開始します。ここで処理中のリクエストの処理が完了しないときは，J2EEアプリケーション実行時間の監視で，一定時間内に終了しなかったメソッド処理をタイムアウトとして通知し，メソッド処理をキャンセルすることで，リロード処理を開始できます。

メソッドキャンセル機能によるリロードを次の図に示します。

図13-14　メソッドキャンセル機能によるリロード（EJBアプリケーションの場合）

構成ファイルの更新検知からリロード処理開始までの時間は次の式で求められます。

構成ファイル更新用インターバル（秒）＋処理中のリクエストの実行待ち時間（秒）

(b)　Webアプリケーションの場合

Webアプリケーションをリロードする場合について説明します。

リロード遅延実行を設定している場合，指定した最大遅延時間を経過すると，J2EEサーバは，新規リクエストを実行待ちにし，処理中のリクエストの処理が完了するのを待ってリロード処理を開始します。ここで処理中のリクエストの処理が完了しないときは，J2EEアプリケーション実行時間の監視で，一定時間内に終了しなかったメソッド処理をタイムアウトとして通知し，メソッド処理をキャンセルすることで，リロード処理を開始できます。

メソッドキャンセル機能によるリロードを次の図に示します。

図13-15　メソッドキャンセル機能によるリロード（Webアプリケーションの場合）

構成ファイルの更新検知からリロード処理開始までの時間は次の式で求められます。

構成ファイル更新用インターバル（秒）＋リロード遅延実行の最大遅延時間（秒）＋処理中のリクエストの実行待ち時間（秒）