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