対応バージョン :	2.2.8
対応エディション :
対応プラットフォーム :

このプロパティには、WrapperがJVMの再起動を試みる最大回数を設定します。 再起動を試みた「起動の試み（invocation）」が異常に終了したり、起動後に短い時間で再起動を繰り返したり、再起動の回数をカウントしていきます。 最低でも「１」を設定しなければならず、デフォルト値は「５回」です。

wrapper.max_failed_invocations=5

例えば、もし、アプリケーションのコンフィギュレーションに間違いがあった場合、 JVMが［ClassNotFoundException］で終了するはずです。 これは、JVMが異常な状態で終了したとして解釈され、JVMの再起動を誘発します。 明らかに、これでは、JVM再起動の無限ループ状態へと突入してしまう可能性もあります。 そのループ問題を解決するために、このプロパティではJVM再起動の最大回数を設定します。

もし、［wrapper.successful_invocation_time］ プロパティで設定された値より長く、JVMが動作を継続した場合、無事に起動が完了したと解釈され、 この再起動の回数が「0 (ゼロ)」へリセットされます。 つまり、このカウントは、スタートアップで失敗したJVMの「起動の試み（invocation）」だけに適用されます。

一般的に、このプロパティは、 ［wrapper.startup.timeout］プロパティ で設定した時間よりも長めの時間を設定するべきで、スタートアップ時やスタートアップ直後の失敗をカウントするように設計されています。

ほとんどのケースでは、このプロパティ値は「１」が好ましいでしょう。 しかし、リソースが即座に有効にならないかもしれない所では、考慮する必要もあります。 例えば、Solaris システム上でのケースです。 サーバーソケットが、前回は制限させた、そのプロセスが終結させられた後、２分まで残るかもしれません。 これは、サーバーが通常どおりにスタートするところのケースへ誘導します。 その後、何日か後に、何かの理由で、JVMが再起動したとき、 新しいJVMの「起動の試み（invocation）」がスタートアップするように試みる時、 ［BindException］をゲットすること。 その値を「５」に設定することで、数回以内にJVM再起動の失敗という見込みを低くさせます。

再起動が、［WrapperManager.restart()］ メソッドを使って、JVMから再起動のリクエストを出します。 フィルターによってキッカケを引き起こされる再起動は、他のいかなる再起動のように取り扱われます。 もし、そのリクエストが、JVMが起動した直後に起こされるならば、再起動の試みとして数えられ、カウントが増えていきます。

• [ wrapper.disable_restarts ] (3.2.0)

  Wrapper による全ての JVM の自動再起動を無効にします。これは、エラーによる再起動や JVM 内部からの再起動リクエストによる再起動を含みます。

• [ wrapper.disable_restarts.automatic ] (3.3.4)

  JVM がクラッシュするときや予想外に終了したときなどを含む、Wrapper による JVM の自動再起動を無効にします。

• [ wrapper.max_failed_invocations ] (2.2.8)

  Wrapper が JVM の再起動を試みる最大回数を設定します。

• [ wrapper.successful_invocation_time ] (2.2.8)

  正常に開始されたとみなされるためにアプリケーションが動作を継続しなければならない最低限の経過時間（秒数）を設定します。

• [ wrapper.startup.timeout ] (1.0.0)

  Wrapper が JVM プロセスを起動してから、JVM 側がアプリケーションのスタートアップが確立したと応答を返すまでの Wrapper の待機時間（秒数）を設定します。