このフィルターは、とても強力な機能で、何もコーディングを必要とせず、 アプリケーションの終了に対する新しい動作を追加するなどが可能です。 JVM のコンソール出力の文字列をモニタリング（監視）することで動作し、 該当する文字列が見つかると、いくつでもアクションを実行することができます。

例えば、エラーが発生したとき JVM を再起動させます。 あるアプリケーションに「ある状況になると動作を停止する」というバグがあるとします。 このフィルター機能を活用すると、 アプリケーションの問題を解決するまで「停止する」という問題を即に回避することが可能になります。

フィルター定義に利用するプロパティ：

• ［wrapper.filter.trigger.<n>］プロパティ（必須）
• ［wrapper.filter.action.<n>］プロパティ（必須）
• ［wrapper.filter.allow_wildcards.<n>］プロパティ（任意）
• ［wrapper.filter.message.<n>］プロパティ（任意）

フィルター定義として、最低でも、 ［wrapper.filter.trigger.<n>］プロパティや ［wrapper.filter.action.<n>］プロパティを 設定しなければなりません。その他のプロパティは任意に応じて設定します。

<n> コンポーネント部：

各フィルターで、 プロパティ名の「<n>」コンポーネント部には、 「1」からカウントアップしていくインテージャー（整数値）のナンバリング数値を入れて指定します。 デフォルトでは、連番であり、欠番で飛ぶことはできないはずです。 ［wrapper.ignore_sequence_gaps］ プロパティで、シーケンス内でギャップ（途切れ）検索を「許可する／許可しない」を任意に設定にすることができます。

「<n>」番号の昇順で、定義されたフィルターをスキャンします。 一つのフィルター条件が一致すると、その出力ラインで処理を停止します。

下記に、いろいろなプロパティの使用例をご紹介していますので参照ください：

• シンプル一致
• ワイルドカードの利用
• 複数のアクションを指定する
• 例外に一致させる方法
• 「OutOfMemoryError」検知

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

このプロパティには、トリガー（キッカケになるもの）の文字列を設定します。 どんな文字でも可能です。このプロパティは必須です。

wrapper.filter.trigger.1=Error
wrapper.filter.action.1=RESTART

トリガーにスペースを含む：

フィルタリングされる文字列にはスペース（空白）を含めることができます。 しかし、一般的にコンフィギュレーションプロパティがロード（読み込み）される処理において、 先頭や末尾にあるスペース（空白）はトリム（切り落とし）されます。

wrapper.filter.trigger.1=  Restart me now.
wrapper.filter.action.1=RESTART

ワイルドカード：

Wrapper バージョン 3.5.5 から、 ［wrapper.filter.allow_wildcards.<n>］プロパティを「TRUE」に設定した場合、 トリガー文字にワイルドカード（「*」や「?」）を含めることが可能です。

有効なワイルドカード文字は次のとおり：

• [*] 文字は、「0 （ゼロ）」か任意の文字列に相当します。
• [?] 文字は、キッチリ１文字に相当します。

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

アクションを実行するには、このプロパティを設定する必須があります。 もしアクションが省略されていた場合、デフォルトの [RESTART] のアクションが実行されます。

wrapper.filter.trigger.1=Error
wrapper.filter.action.1=RESTART

可能なアクションは次のとおり：

• [DEBUG] （ver. 3.5.0 から）：

  デバッグメッセージをログ化します。 これは、アクションの発生を把握できるので、とても役立ちます。 will cause a debug message to be logged. This is only really useful in helping to understand when the action is fired.

• [DUMP] （ver. 3.3.6 から）：

  スレッドダンプを生成します。

• [GC] （ver. 3.5.7 から）：

  JVM で完全なガベージコレクション掃除を実行します。 完全な掃除をすると、ガベージコレクション中、しばしば全てのスレッドがフリーズしたりなど引き起こすため、 これを頻繁にすると JVM のパフォーマンスに影響しますのでご理解ください。

• [RESTART] ：

  現在の JVM を停止して、新しい「起動の試み（invocation）」として再起動します。

• [SHUTDOWN] ：

  Wrapper 同様に、JVM を終了します。

• [USER_<n>] （ver. 3.5.0 から）（プロフェッショナル版）：

  ユーザー定義イベントを発生させます。 イベントには、「メール送信」か、 「外部システムコマンドの実行」か、 どちらかのアクションが可能です。 そのコマンド指定には、クリーンアップ作業や SNMP トラップを起こしたり、何でも可能です。

• [PAUSE] （ver. 3.5.0 から）：

  ポーズ（一時停止）が可能で JVM が動作している場合、Java アプリケーションをポーズ（一時停止）します。 詳しくは［wrapper.pausable］プロパティをご覧ください。

• [RESUME] （ver. 3.5.0 から）：

  JVM がポーズ（一時停止）状態にあるとき、Java アプリケーションをレジューム（再開）します。 これは、JVM が停止ではなくポーズ（一時停止）している場合に利用可能です。 詳しくは［wrapper.pausable］プロパティをご覧ください。

• [SUSPEND_TIMEOUTS_<n>] （ver. 3.5.40 から）（スタンダード版、プロフェッショナル版）：

  JVM が応答しない場合、全てのタイムアウトを停止するように指示します。 「<n>」は、タイムアウトを停止する期間（秒数）を指定し、1-3600 （１秒から１時間まで）の範囲で設定できます。 これは、Java アプリケーションが長いブロックタスクを実行する必要がある時に Wrapper がアプリケーションが応答不能と判断するのを防ぐために使用できます。

  その他のアクションプロパティ、コマンドファイル、或いは Java WrapperManager.suspendTimeouts() メソッドでタイムアウトを停止することができます。

  タイムアウトを停止するリクエストが複数ある場合、各リクエストで指定されている秒数は加算されません。 代わりに、新しく指定された秒数が残りの停止期間より長い場合、停止期間が置き換えられますが、 それより短い場合は無視されます。

• [RESUME_TIMEOUTS] （ver. 3.5.40 から）（スタンダード版、プロフェッショナル版）：

  Wrapper に、停止された全てのタイムアウトを再開するように指示します。

  その他のアクションプロパティ、コマンドファイル、或いは Java WrapperManager.resumeTimeouts() メソッドでタイムアウトを再開することができます。

• [NONE] ：

  何のアクションも起こしません。 高いナンバリング数値で設定されているトリガーを、フィルター検索の対象から除外することができるので、便利です。

複数のアクションを指定する：

Wrapper バージョン 3.5.0 から、スペースやカンマで区切ることで、複数のアクションを指定することが可能です。 複数のアクションを指定すると、迅速に指定した順番で続けて実行されます。

次の例は、トリガー条件に一致した場合、スレッドダンプを実行して、その後、JVM を再起動します。

wrapper.filter.trigger.1=Error
wrapper.filter.action.1=DUMP,RESTART

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

このプロパティには、［wrapper.filter.trigger.<n>］ プロパティに設定するトリガー文字にワイルドカードを「利用する (TRUE)／利用しない (FALSE)」を設定します。 もし TRUE に設定すると、 ［wrapper.filter.trigger.<n>］ フィルターに含まれているワイルドカードを処理します。詳しくは下記の使用例を参照ください。

wrapper.filter.allow_wildcards.1=TRUE

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

この［wrapper.filter.message.<n>］プロパティには、トリガーが発生したとき、ユーザーに表示するメッセージ>を設定します。 何が起きているのか、ユーザーに説明するのに、とても便利です。 デフォルト値は「Filter trigger matched.」です。

wrapper.filter.trigger.1=java.lang.OutOfMemoryError
wrapper.filter.action.1=RESTART
wrapper.filter.message.1=The JVM has run out of memory.

このセクションでは、トリガーを最大に活かす様々な使用例ご紹介します。 フィルターは、JVM のコンソール出力をモニタリング（監視）することで動作します。 トリガーが例外で発動されるようにするために、 Java アプリケーションが、コンソールへフィルタリングされたメッセージを表示しなければなりません。

• シンプル一致
• ワイルドカードの利用
• 複数のアクションを指定する
• 例外に一致させる方法
• 「OutOfMemoryError」検知

wrapper.filter.trigger.1=Error
wrapper.filter.action.1=RESTART

jvm 1    | 次のラインで、WrapperがJVMを再起動させるはず:
jvm 1    |   エラー
wrapper  | フィルタートリガーが一致しました。JVM 再起動中。
wrapper  | JVM 起動中...
jvm 2    | WrapperManager: 初期化中...

wrapper.filter.trigger.1=Head*Tail-?
wrapper.filter.allow_wildcards.1=TRUE
wrapper.filter.action.1=RESTART

jvm 1    | 次のラインで、WrapperがJVMを再起動させるはず:
jvm 1    |   Head a bunch of stuff, then Tail-1 and some more stuff.
wrapper  | フィルタートリガーが一致しました。JVM再起動中。
wrapper  | JVM起動中...
jvm 2    | WrapperManager: 初期化中...

wrapper.filter.trigger.1=User Error
wrapper.filter.action.1=DUMP,RESTART

jvm 1    | 次のラインで、WrapperがJVMを再起動させるはず:
jvm 1    |   User Error
wrapper  | フィルタートリガーが一致しました。スレッドダンプをリクエスト中。
wrapper  | JVM 状況をダンピング中。
wrapper  | フィルタートリガーが一致しました。JVM 再起動中。
jvm 1    | Full thread dump Java HotSpot(TM) Client VM (1.5.0_24-149 mixed mode, sharing):
jvm 1    | 
jvm 1    | "WrapperSimpleAppMain" prio=5 tid=0x0100f400 nid=0x86c600 waiting on condition [0xb0e8e000..0xb0e8ed90]
jvm 1    | 	at java.lang.Thread.sleep(Native Method)
jvm 1    | ...
jvm 1    | "Exception Catcher Thread" prio=10 tid=0x01001910 nid=0x80ac00 runnable 
wrapper  | JVM起動中...
jvm 2    | WrapperManager: 初期化中...

wrapper.filter.trigger.1=IgnoreError
wrapper.filter.action.1=NONE
wrapper.filter.trigger.2=Error
wrapper.filter.action.2=RESTART

jvm 1    | 次のラインは無視されるはずです:
jvm 1    |   IgnoreError
jvm 1    | 
jvm 1    | 次のラインで、Wrapper が JVM を再起動させるはず:
jvm 1    |   エラー
wrapper  | フィルタートリガーが一致しました。JVM 再起動中。
wrapper  | JVM 起動中...
jvm 2    | WrapperManager: 初期化中...

wrapper.filter.trigger.1=java.lang.OutOfMemoryError
wrapper.filter.action.1=RESTART

jvm 1    |  186:             6            384  sun.reflect.generics.repository.MethodRepository
jvm 1    |  187:             8            384  java.lang.OutOfMemoryError
wrapper  | The JVM has run out of memory.  Restarting JVM.
jvm 1    |  188:             8            384  java.io.OutputStreamWriter
jvm 1    |  189:             1            376  java.awt.Checkbox

wrapper.filter.trigger.1=Exception in thread "*" java.lang.OutOfMemoryError
wrapper.filter.allow_wildcards.1=TRUE
wrapper.filter.action.1=RESTART
wrapper.filter.message.1=The JVM has run out of memory.

jvm 1    | Mention the java.lang.OutOfMemoryError exception (Not triggered)
jvm 1    | 
jvm 1    | Now thow a new java.lang.OutOfMemoryError to invoke a stack trace:
jvm 1    | Exception in thread "MyApp-Main" java.lang.OutOfMemoryError
wrapper  | The JVM has run out of memory. JVM 再起動中。
jvm 1    |      場所： com.myapp.Main.doSomething(Main.java:321)
jvm 1    |      場所： com.myapp.Main.main(Main.java:654)
wrapper  | JVM起動中...
jvm 2    | WrapperManager: 初期化中...

jvm 1    |   wrapper.filter.trigger.1=Exception in thread "*" java.lang.OutOfMemoryError
wrapper  | The JVM has run out of memory.  Restarting JVM.

wrapper.filter.trigger.1=Exception in thread "*" java.lang.OutOfMemoryError
wrapper.filter.action.1=NONE

wrapper.filter.trigger.2=Exception in thread "*" java.lang.OutOfMemoryError
wrapper.filter.allow_wildcards.2=TRUE
wrapper.filter.action.2=RESTART
wrapper.filter.message.2=The JVM has run out of memory.