従来からの方式で、Wrapperは、内部の時間想定に、常にシステム時間を利用します。 主要なケースでは、これで完璧に動作します。 しかしながら、動作に失敗したり、Wrapperが期待どおりに動作しないケースも、２, ３つあります：

• もしWrapperが、 高い優先度で稼働している他のプロセスと、CPUの奪い合いで争う状況にある場合、 WrapperやJVMのどちらか、または両方とも、 長い時間、CPUサイクルを取得できない、という可能性があります。 Wrapperは常にこれらのケースをその状況を検知するロジックで取り扱い、 影響を受けたタイムアウトを適切に延長します。 しかしながら稀なケースでは、 Wrapperは「JVMがフリーズしている」と勘違いして、JVMを再起動させます。

• システム時間の変更。 もし、Wrapperの動作中に、２，３秒以上、前に進めるにしろ後へ戻すにしろ、 システム時間が変更された場合、 １つか複数かのタイムアウトがトリガーされる可能性があり、 結果として、意図としないJVM再起動が引き起こされることがあります。 ほとんどのケースでは、プロセスがCPU不足に陥ったときと同じように、 Wrapperは時間変更をうまく取り扱います。 しかし、それが失敗するケースもあります。

  一般的に、システム時間を前に進める設定は、正しく動作します。 「x 秒間にWrapperがCPUを受信していない」というメッセージがコンソールに表示され、 ユーザーに知らせますが、Wrapperは正しく動作を継続します。

  しかしながら、システム時間を逆戻しにする設定は、 その時のWrapperステート（状態）にもよりますが、多くの問題が起きます。 内部的に、Wrapperは、 pingを送信したり、新しいJVMを起動するなど、動作が発生するときに、 ある特定の時間にイベント予約を組み込んでいます。 もし、時間を１時間の逆戻りで設定すると、 ５秒後に予定されていた動作が１時間５秒の間は起きません。 もし、このタイミングが揃った場合、 WrapperはJVMへのping送信を停止して、 JVM側ではpingの未着に応答して、JVM再起動を起こします。

  注意

  夏時間（Daylight Savings Time）

  Wrapperは夏時間に対応して動作しません。 もし春や秋に時間が変わる国に住んでいる場合、 そのタイムアウトの問題を回避するために、 ティックタイマーを利用することをお薦めします。

  上記で述べたように、 春や秋にシステム時間の調整時に、JVM再起動が起きることもありますが、 一旦、JVMが再起動されれば、 アプリケーションは正しく動作を継続するはずです。

• システムサスペンド（一時停止）とレジューム（再開）。 もし、ディスクやRAMに長時間サスペンドされるようなシステム上で Wrapperが利用されている場合、 マシンがレジューム（再開）したとき、システム時間が進んでいることがあります。 コンソールメッセージが表示されますが、これは正しく動作します。

Wrapperバージョン3.1.0の時点で、新しいタイマーの仕組みがWrapperに追加されました。 この新しいタイマーは、Wrapperバージョン3.2.0でデフォルトになっています。 システムクロックに時間を問い合わせ続けるのではなく、 Wrapperは、軽量のループ状態に入り、内部の“ティック”カウンターを実装する バックグランドスレッドを作成します。 内部的に全ての時間測定が、この“ティック”をベースにして、修正されます。 （もし、このシステム時間が利用されていて、いかなる独特の瞬間でも、 ティックカウントが、カウンタではなく、システム時間から計算されます）

これにより結果として、多くの利点があります：

• 前に進めるにしろ後へ戻すにしろ、システム時間が変更されたとしても、 もはやWrapperは何も影響を受けることはありません。 夏時間やその他の時間調整を行っても、Wrpperは確実に正しく動作します。

• サスペンド（一時停止）されたシステムがレジューム（再開）するとき、 いかなる問題もなく、中断したところからWrapperは再開して継続します。

• 絶対的な一定速度ではなく、 CPU受信量に応じて柔軟に変動する速度でカウントが増えていく ティックカウントを利用しているため、 Wrapperは、CPU不足のステート（状態）で動作するケースも確実に取り扱います。 つまり、高い負荷が原因でおきるタイムアウトが発生するのは、 非常に稀なことになります。

  極端なケースでは、 もしWrapperがCPUを受信していても、JVMが完全に不足している場合、 あるいは、その逆もまた同じですが、 タイムアウトが起きる可能性もあります。 しかしながら、この２つのプロセスが常に全く同じ優先度で運用されている場合で、 だから、これは非常に稀なことです。

時間測定に“ティック”カウンターを利用すると、欠点になる場合もあります：

• ティックタイマーは、 ネイティブWrapper内部に、追加のスレッドを配置する必要があります。 その結果、Wrapperの動作に必要なリソースが少し増加します。

  WrapperのJava側は、 システムシグナルをチェックするために既に利用されたスレッドを活用します。 そのため、Java側にリソースの増加はありません。

• 100％CPU以下の負荷の状態では、 タイマースレッドは常に十分なCPUを取得して、 時間的に正確なリズムで、カウントを増やしていきます。 しかし、システムが100％CPUで動作しているとき、 スレッドはフルスピードでループすることができず、 結果として、もっと遅い速度でのカウント増加となります。 ほとんどのケースでは、これは実際には良いことなのです。 しかしながら、 pingインターバル（一定間隔）のような動作にも影響を及ぼし、 時々、不正確なリズムにもなり、あまり好ましくありません。 この事実もしっかり理解しておく必要があります。

この［wrapper.timer_slow_threshold］ プロパティは、 タイマースレッドのシングルループ内部で、 “ティック”タイマーがシステム時間より「しきい値」の秒数以上の遅れを取ったとき、 ログへメッセージを表示します。 このプロパティのデフォルト値は、事実上、無効にするために非常に高く設定されています。

wrapper.timer_slow_threshold=10

遅れの“しきい値”を「１秒」のような低い値に設定すると、 日中のいつ、システムに負荷がかかったか、役に立つ情報を提供します。

「0 (ゼロ)」の値では、各シングルスリップごとを示し、 一般的にそれほど役に立ちません。 非常に軽い負荷の状況下であっても、 タイマーは、ループ自体が完了するまでに限られたな時間数を要するため、 それだけでも単純にシステムクロックより少し遅れを取ります。

各シングルCPUの一時的な中断もこまめにログ化せずに、 システム上の高い負荷がかかった場合だけの主要な時間を指定する、 「10秒」のようなやや高めの値は、実際にかなり役に立ちます。

システムクロックを前に進める調整は、 クロックが前に進む所要時間が続いた CPUの高い負荷の時間として解釈されます。

例えば、もし、このプロパティを低い値に設定して、 システムクロックを１分進めるか、１分間の非常に重い負荷の状態か、 どちらかに設定された場合、 下記のようなログ出力が表示されます：

INFO   | Wrapper  | 2004/07/21 08:52:01 | タイマーは、システムクロックより 60000ミリ秒、遅れをとりました。
INFO   | jvm 1    | 2004/07/21 08:52:15 | タイマーは、システムクロックより 60000ミリ秒、遅れをとりました。

メッセージの組み合わせで、WrapperとJVMの両方のプロセスが、 システム時間に変更をあったことに気づいていることを示しています。 これが単に重い負荷により引き起こされている場合、 ２つのプロセスから報告される数字が、やや異なるのは、かなり一般的なことです。

この［wrapper.timer_fast_threshold］ プロパティは、 タイマースレッドのシングルループ内部で、 システム時間が“ティック”タイマーより「しきい値」の秒数以上の遅れを取ったとき、 ログへメッセージを表示します。 このプロパティのデフォルト値は、事実上、無効にするために非常に高く設定されています。

wrapper.timer_fast_threshold=0

進み過ぎ「しきい値」を低い値に設定すると、一般的に、 上記の遅れの「しきい値」プロパティほど役に立ちません。 通常の稼働状況下で、 “ティック”タイマーは決してシステム時間より前に進むことはありません。 唯一の例外として、システムクロックが遅れるケースはあります。 このプロパティ値を「0 (ゼロ)」に設定すると、 システムクロックの逆戻し調整を検知します。

例えば、もし、このプロパティを低い値に設定して、 システムクロックを１分後ろ戻す設定すると、下記のようにログに出力されます：

INFO   | Wrapper  | 2004/07/21 08:52:01 | システムクロックは、タイマーより60000ミリ秒 遅れをとりました。
INFO   | jvm 1    | 2004/07/21 08:52:15 | システムクロックは、タイマーより60000ミリ秒 遅れをとりました。

メッセージの組み合わせで、 WrapperとJVMの両方のプロセスでシステム時間に変更をあったことを示しています。