|
警告
|  |
このプロパティの説明を読まずに、パラメーターを変更することは絶対にしないで下さい。
設定を間違えると、期待どおりに動作せず、Wrapperの動作不良や不具合の原因となります。
|
このプロパティには、JVMが警告を発信してタイムアウトを延長する前の、
CPUを利用していない時間数（秒数）を設定します。
このプロパティに効果を持たせるためには、
他のタイムアウト
（wrapper.startup.timeout、
wrapper.ping.timeout、
wrapper.shutdown.timeout）
より下回る値でなければなりません。
プロパティ値を「0 (ゼロ)」に設定すると、タイムアウト（時間切れ）の延長は発生しません。
デフォルト値は「10秒」です。
もしWrapperが延長された時間数の間にCPUを利用していない、と検知した場合、
下記のようなWrapperやJVMあるいは両方からのメッセージを目にするかもしれません。
INFO | Wrapper | Wrapper Process has not received any CPU time for 27 seconds.
Extending timeouts.
INFO | jvm 1 | JVM Process has not received any CPU time for 27 seconds.
Extending timeouts.
|
このケース例では、これらのメッセージは、警告で、
Wrapper と JVMプロセスの両方が、27秒間CPUへのアクセスが拒否されました。
現在のWrapperのステート（状態）次第で、
スタートアップ、ping、あるいは、シャットダウンのどれかのタイムアウトが、
処理力の不足が原因の「FALSE」タイムアウトを避けるために、延長されています。
２つのケースが考えられ、
Wrapperか、コントロールされているJVMか、どちらかが、
延長された時間数の間に、CPUへのアクセスを拒否されています。
どちらのケースであっても、
タイムアウトの期限切れが１回か数回か発生しているため、
WrapperがJVMがハングアップしたと想定して、
再起動あるいはシャットダウンを誘発しています。
これが起こりうる最初の道は、
Wrapperが他のプロセスへ譲歩することなく、
延長された時間数の間、CPU100％消費をする慣性を持つ他のプロセスと競合して、
システム・リソースの奪い合いっているときです。
ほとんどの現代のOS（オペレーティング・システム）では、
マルチタスク管理に関して、適正に動作しますが、中には、失敗するケースもまだあります。
Windows上でのこの１例をあげると、
マシンのメモリが低く、たくさんのディスク・スワッピングへ導びく例です。
もし総メモリが十分に大きい場合、
アプリケーションに再びCPUサイクルが提供される前の１分足らずの間に
システム全体がフリーズすることもあります。
ほとんどのケースでは、CPUタイムアウト問題に悩んでいる場合、
タイムアウトを延長するという手法ではなく、
CPUを取得できないWrapperの問題を解決する道を見つけるべきです。
Wrapperによって動かされているアプリケーションがCPUを取得しない場合、
クライアントからのリクエストを確実にサービスすることができないでしょう。
２番目の道は、もしシステムがサスペンドされたら、レジューム（再開）することです。
これはノートブックのパソコンでは一般的なことです。
システムが復帰したとき、
システムは突然に数時間進んで設定されているように見えることがある可能性があります。
デフォルトでは、警告メッセージは、10秒後に表示されます（実際にはかなり長く感じると思います）。
トリガーされたCPUタイムアウトは、
ログ内に表示されているメッセージ以外のアプリケーション上で何も逆効果はありません。
タイムアウトがログ記録されたこのメッセージを避けるためには、大きい値を設定するか、完全に無効にしてください。
| 設定例： |
wrapper.cpu.timeout=10
|
|
警告
| |
その能力がある間. While the ability is there.
このプロパティを「0 （ゼロ）」か、あるいは「他のタイムアウトより大きくい値」を設定すると、
重い負荷が発生するケースで、タイムアウトが不正にトリガーされる可能性がある、
ということに注意してください。
これは、本当に再起動が必要ない場合にでも、JVM再起動を誘発することができます。
|
|
