| ディレクティブ | ワーカートタイプ | デフォルト | 説明 |
|---|
connect_timeout | AJP、SUB | 0 | 接続が確立された後、ajp13接続でPINGリクエストを送信するようにウェブサーバーに指示する接続タイムアウトプロパティ。パラメーターは、PONG応答を待つミリ秒単位の遅延です。デフォルト値のゼロはタイムアウトを無効にします（無期限タイムアウト）。 この機能はjk 1.2.6で追加され、ハングしたTomcatの問題を回避し、Tomcat 3.3.2+、4.1.28+、および5.0.13+で実装されたajp13 ping/pongサポートを必要とします。デフォルトでは無効になっています。
|
prepost_timeout | AJP、SUB | 0 | リクエストを転送する前に、ajp13接続でPINGリクエストを送信するようにウェブサーバーに指示するprepostタイムアウトプロパティ。パラメーターは、PONG応答を待つミリ秒単位の遅延です。デフォルト値のゼロはタイムアウトを無効にします（無期限タイムアウト）。 この機能はjk 1.2.6で追加され、ハングしたTomcatの問題を回避し、Tomcat 3.3.2+、4.1.28+、および5.0.13+で実装されたajp13 ping/pongサポートを必要とします。デフォルトでは無効になっています。
|
reply_timeout | AJP、SUB | 0 | 読み取りイベント中に成功を待つミリ秒数のパラメーター。これは、リクエストの完全な応答時間に対するタイムアウトではなく、Tomcatから受信した2つのパケット間の最大時間です。通常、最も長いポーズは、リクエストを送信してから応答の最初のパケットを取得する間です。 Tomcatからデータを受信せずにタイムアウトが経過すると、ウェブサーバーは応答の残りを待たずにクライアント（ブラウザ）にエラーを送信します。通常、これはリクエストがTomcatバックエンドでも中止されることを意味するわけではありません。ワーカーがロードバランサのメンバーである場合、ロードバランサはワーカーをエラー状態にして、別のメンバーでリクエストを再試行する可能性があります。max_reply_timeouts、retries、およびrecovery_optionsも参照してください。
デフォルト（値ゼロ）では、ウェブサーバーは無期限に待ち続けます。これは問題になる可能性があります。reply_timeoutを設定する場合は、長時間実行されるサーブレットがある場合は注意深く調整してください。
reply_timeoutは、Apache HTTP Server環境変数JK_REPLY_TIMEOUTとreply_timeoutのワーカーマップ拡張を使用して上書きできます。
この機能はjk 1.2.6で追加され、ajp13をサポートするすべてのサーブレットエンジンで動作します。変数JK_REPLY_TIMEOUTとワーカーマップ拡張は、バージョン1.2.27で追加されました。
|
再試行回数 | AJP、SUB | 2 |
このディレクティブは、ロードバランサワーカーにも存在します。それらについては、異なる意味を持ちます。通信エラーが発生した場合に、ワーカーがTomcatにリクエストを送信する最大回数。各再試行は別の接続で行われます。最初の試行もカウントされるため、retries=2はエラー後の1回の再試行を意味します。再試行の前に、ワーカーは設定可能なスリープ時間待ちます。 再試行のより詳細な制御については属性recovery_options、スリープ時間の設定についてはretry_intervalも参照してください。
バージョン1.2.16までは、デフォルト値は3でした。
|
retry_interval | AJP、SUB | 100 | 再試行を行う前にワーカーがスリープするミリ秒単位の時間。 この機能はjk 1.2.27で追加されました。
|
recovery_options | AJP、SUB | 0 | 復旧オプションは、Tomcatで問題を検出した場合の再試行の処理方法に影響を与えます。再試行回数は属性retriesで制御されます。 この属性はビットマスクです。次のビットが許可されます。
1：リクエストの取得後にTomcatが失敗した場合、復旧しません。
2：クライアントにヘッダーを送信した後にTomcatが失敗した場合、復旧しません。
4：クライアント（ブラウザ）への応答を書き戻す際にエラーを検出した場合、Tomcatへの接続を閉じます。
8：HTTPメソッドHEADのリクエストは常に復旧します（ビット1または2が設定されている場合でも）。
16：HTTPメソッドGETのリクエストは常に復旧します（ビット1または2が設定されている場合でも）。
この機能はjk 1.2.6で追加されました。オプション4はバージョン1.2.16、オプション8と16はバージョン1.2.24で追加されました。
|
fail_on_status | AJP、SUB | 0 | サーブレットコンテナから返された場合にワーカーが失敗するHTTPステータスコードにこの値を設定します。このディレクティブを使用して、サーブレットコンテナが短時間（例：再デプロイメント中）に一時的に200以外の応答を返す場合に対処します。 元の応答のエラーページ、ヘッダー、およびステータスコードはクライアントに送り返されません。代わりに、リクエストは503応答になります。ワーカーがロードバランサのメンバーである場合、メンバーはエラー状態になります。リクエストのフェイルオーバーとワーカーの復旧は、通常のロードバランサの手順で処理されます。
この機能はjk 1.2.20で追加されました。
jk 1.2.22以降、スペースまたはコンマ文字で区切られた複数のステータスコードを定義できます。たとえば：worker.xxx.fail_on_status=500,503
jk 1.2.25 以降、ロードバランサに対して、`fail_on_status`に含まれるステータスコードで応答が返された場合でも、メンバをエラー状態にしないよう指示できます。この機能は、ステータスコードの前にマイナス記号を付けることで有効になります。例：worker.xxx.fail_on_status=-404,-500,503
|
busy_limit | AJP、SUB | 0 | 正の値に設定すると、ワーカーは現在処理中の同時リクエスト数がこの数値未満の場合のみ、リクエストに使用されます。 これは、Busyness ロードバランシング方式とは関係ありません。
この機能は実験的で、jk 1.2.41に追加されました。
|
max_packet_size | AJP、SUB | 8192 | この属性は、AJP パケットの最大サイズ（バイト単位）を設定します。1024 の倍数である必要があります。1024 の倍数でない設定値は、次の 1024 の倍数に調整されます。最大値は 65536 です。デフォルト値を変更する場合は、Tomcat側のAJPコネクタの`packetSize`属性も変更する必要があります！`packetSize`属性はTomcat 6.0.2以降で使用できます。 通常、最大パケットサイズを変更する必要はありません。デフォルト値に関する問題は、証明書または証明書チェーンを送信する場合に報告されています。
この機能はjk 1.2.19に追加されました。
|
prefer_ipv6 | AJP、SUB | false | IPV6サポート付きでコンパイルした場合、このディレクティブは、IPV6アドレスとIPV4アドレスの両方を持つホスト名のIPV6アドレス解決を強制します。指定されたホスト名にIPV6アドレスが定義されていない場合、このディレクティブは無効になります。IPV6アドレスのみが定義されている場合、またはIPV4またはIPV6表記でIPアドレスが"host"に使用されている場合も、このディレクティブは無効になります。 この機能はjk 1.2.38で追加されました。
|
secret | AJP,SUB,LB | - | Tomcat AJPコネクタに秘密キーワードを設定できます。設定すると、同じ秘密キーワードを持つワーカーからのリクエストのみが受け付けられます。 Tomcat AJPコネクタの設定でsecret="secret key word"属性を使用してください。（歴史的注記：属性名は、2020年2月より前にリリースされたTomcat 9.0、8.x、7.0バージョンではrequiredSecret、Tomcat 6.0以前ではrequest.secretでした。）
ロードバランサに秘密キーワードを設定すると、そのすべてのメンバがこの秘密キーワードを継承します。
この機能はjk 1.2.12で追加されました。
|
mount | AJP,LB | - | ワーカーが処理するURIマップのスペース区切りリストです。ワーカーが`worker.list`に含まれている場合にのみ使用されます。 このディレクティブは、同じワーカーに対して複数回使用できます。
|
max_reply_timeouts | LB | 0 | ロードバランサワーカーのメンバにreply_timeoutを使用していて、`reply_timeout`より時間がかかるリクエストをいくつか許容したい場合は、この属性を正の値に設定できます。 長時間実行されるリクエストは、データの待ち時間`reply_timeout`ミリ秒後にタイムアウトしますが、対応するメンバワーカーは、`max_reply_timeouts`を超えるリクエストがタイムアウトした場合にのみ、エラー状態になります。より正確には、これらの不良リクエストのカウントは、ロードバランサが内部メンテナンスを実行するたびに2で割られます（デフォルトでは60秒ごと）。
この機能は、jk 1.2.24で追加され、散発的な長時間実行リクエストに対するreply_timeoutの感度を低くしました。
|
recover_time | LB | 60 | リカバリ時間は、ロードバランサがエラー状態になった後、ワーカーを使用しようとしない時間（秒単位）です。この時間が経過した後のみ、エラー状態のワーカーはリカバリ中としてマークされ、新しいリクエストで試行されます。 この間隔は、リクエストが処理されるたびにチェックされるわけではありません。代わりに、グローバルメンテナンス中にチェックされます。グローバルメンテナンスの実行間隔は、`worker.maintain`で制御されます。
影響を理解していない限り、`recover_time`を非常に短い時間に設定しないでください。エラー状態のワーカーに対するすべてのリカバリ試行は、実際のリクエストによって行われます！
|
error_escalation_time | LB | recover_time / 2 | ロードバランサのメンバをエラー状態にすることは非常に深刻です。例えば、スティッキーセッションが必要な場合、該当ノードのセッションへのアクセスがすべてブロックされます。 ノードが完全に壊れているかどうかを正確に示す情報が提供されないエラー検出の種類があります。そのような場合、LBはノードをすぐにエラー状態にしません。そのようなエラーが発生した後、error_escalation_time秒間成功した応答がない場合にのみ、ノードはエラー状態になります。
この機能はjk 1.2.28で追加されました。
|
session_cookie | LB | JSESSIONID | セッションスティッキネスに必要なルーティング識別子を含むCookieの名前です。ルーティング識別子は、Cookieの値にある「.」文字の後のすべてです。 この機能はjk 1.2.27に追加されました。
|
session_path | LB | ;jsessionid | セッションスティッキネスに必要なルーティング識別子を含むパスパラメータの名前です。ルーティング識別子は、パスパラメータの値にある「.」文字の後のすべてです。 この機能はjk 1.2.27に追加されました。
|
set_session_cookie | LB | false | セッションスティッキネスCookieの生成を有効にします。通常は必要ありません。 一部のWebフレームワークはTomcatセッション管理を置き換え、セッションIDの生成方法が異なります。その結果、TomcatによってセッションIDの最後に追加されたルーティングIDが失われ、スティッキーロードバランシングを実行できなくなります。回避策として、次の手順を使用できます。
- 「session_cookie」属性を使用して、非標準のCookie名を選択します。
- 「set_session_cookie」属性をtrueに設定して、Cookieの送信を有効にします。
- 「session_cookie_path」属性を正しいアプリケーションURI（例：「/myapp/」）に設定します。
Cookieは、リクエストに既に同じ名前のCookieが含まれていない場合、またはそのCookieにロードバランサが対応できるルーティングIDが含まれていない場合にのみ送信されます。特にノードのフェイルオーバー後、新しいノードにスティッキネスを切り替えるために新しいCookieを送信します。
この機能はjk 1.2.38で追加されました。
|
session_cookie_path | LB | - | この属性は、「set_session_cookie」がtrueに設定されている場合にのみ使用されます。「set_session_cookie」の説明を参照してください。「session_cookie_path」の値が空の場合（デフォルト）、送信されるCookieにはPATH情報は含まれません。 この機能はjk 1.2.38で追加されました。
|
activation | SUB | Active | このディレクティブを使用して、ロードバランサのバランスされたワーカーを無効または停止として設定できます。無効なワーカーは、そのワーカーのセッションに属するリクエストのみを受け取ります。停止したワーカーは、リクエストを受け取りません。停止したワーカーのユーザーは、クラスタリングによるセッションレプリケーションを使用していない限り、セッションを失います。 無効にするにはdまたはD、停止するにはsまたはSを使用します。このディレクティブが存在しない場合、非推奨のディレクティブ「disabled」または「stopped」が使用されます。
このフラグは、`status worker`を使用して実行時に変更できます。
この機能はjk 1.2.19に追加されました。
|
route | SUB | worker name | 通常、ロードバランサ内のバランスされたワーカーの名前は、対応するTomcatインスタンスの`jvmRoute`と同じです。異なるバランシング設定（例：無効、停止）を持つ複数のロードバランサに対応するTomcatインスタンスのワーカーを含めたい場合は、この属性を使用できます。 任意のワーカー名を持つLBごと、Tomcatインスタンスごとに個別のワーカーを定義し、ワーカーの`route`属性をターゲットTomcatインスタンスの`jvmRoute`に設定します。
この属性を空のままにすると、ワーカーの名前が使用されます。
この属性は、`status worker`を使用して実行時に変更できます。
ルート名にピリオドが含まれている場合、明示的に`domain`が設定されていない限り、最初のピリオドの手前の部分がドメイン名として使用されます。
この機能はjk 1.2.16で追加されました。
自動ドメインルールはjk 1.2.20で追加されました。
この属性の名前は、jk 1.2.20で`jvm_route`から`route`に変更されました。
|
distance | SUB | 0 | lbワーカーのバランスされたワーカー間の優先順位を表す整数です。ロードバランサは、距離が短い別の使用可能なワーカーが存在する場合、一部のバランスされたワーカーを選択しません。 指定された距離以下のすべてのワーカーがエラー、無効、または停止状態の場合にのみ、距離の大きいワーカーがバランシングの対象となります。
この機能はjk 1.2.16で追加されました。
|
domain | SUB | - | ドメインディレクティブは、ワーカーがロードバランサのメンバである場合にのみ使用できます。同じドメイン名を持つワーカーは、単一のワーカーとして扱われます。`sticky_session`を使用する場合は、ドメイン名がセッションルートとして使用されます。 このディレクティブは、6つ以上のTomcatを持つ大規模システムで使用され、Tomcatを2つのグループにクラスタ化し、それらの間のセッションレプリケーション転送を削減します。
この機能はjk 1.2.8で追加されました。
|
redirect | SUB | - | 優先されるフェイルオーバーワーカーの名前に設定します。セッションIDに一致するワーカーがエラー状態の場合、代わりにリダイレクトワーカーが使用されます。無効になっている場合でも使用されるため、ホットスタンバイを提供します。 "route"属性でルートを明示的に設定する場合は、"redirect"を優先されるフェイルオーバーワーカーのこのルートに設定し、その名前に設定しないでください。
この機能はjk 1.2.9で追加されました。
|
