wrapper.max_failed_invocations プロパティ

対応バージョン :2.2.8
対応エディション :プロフェッショナル版スタンダード版コミュニティー版
対応プラットフォーム :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/OSIBM z/Linux

警告

このプロパティの説明を読まずに、パラメータを変更することは絶対にしないで下さい。 設定を間違えると、期待どおりに動作せず、Wrapperの動作不良や不具合の原因となります。

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

設定例:(デフォルト値5回)
wrapper.max_failed_invocations=5

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

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

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

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

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

参照: 再起動/スタートアップ