Executor モードは、デフォルトモードで、Java エージェント 20.11 リリース以降の非同期タスクをインストゥルメント化します。
エージェントが Executor モードになっている場合、トランザクション アクティビティは、Executor.exeute() および同様のメソッドをインストゥルメント化してスレッド間でトラッキングされます。そのため、エージェントは、スケジュールされている場合にトラッキングするアプリケーション動作を識別できます。
Executor モードの利点
- ほとんどの使用例において、エージェントのリソース消費を削減します
- 新しいエージェント API を使用してスレッドハンドオフの追跡を有効にします
- ティア非同期トランザクションの境界で最後のスレッドの信頼性を向上します
- サービスエンドポイントが、非同期フレームワークを使用して実装されたサービスの応答時間を測定できるようにします
Executor モードでのサービスエンドポイントの動作
サービスエンドポイントの動作は、Constructor モードと Executor モードでは異なります。Constructor モードでは、各非同期トランザクションセグメントが独自のサービスエンドポイントによって表され、トランザクション エントリ ポイントに対応するサービスエンドポイントには、次のように開始スレッドの実行時間が表示されます。
Executor のインストゥルメンテーション方式を使用すると、単一のサービスエンドポイントのメトリックが報告され、次のように非同期トランザクション全体の実行時間に対応する応答時間が表示されます。
現在,各サービスのエントリポイントはトランザクション エントリ ポイントと一致している必要があります。非同期トランザクションの実行中の他のポイントでのサービスエンドポイント設定は、Executor モードではサポートされていません。また、サービスエンドポイントは、エージェントが Executor モードのときに、ビジネストランザクションを実行するコンテキスト内に配置された場合にのみ報告されます。
未処理スレッドのサポート
未処理スレッドのサポートは、Executor モードと Constructor モードでは異なります。Constructor モードはトランザクションのコンテキストで作成されたすべてのスレッドのトラッキングをサポートしますが、Executor モードはトランザクションのコンテキストで開始される非デーモンスレッドのみをサポートします。デーモンのステータスは親スレッドから継承され、予期しない結果が発生する可能性があります。たとえば、アプリケーションサーバのワーカースレッドは多くの場合、デーモンスレッドであるため、サーブレットコード内で直接開始されたスレッドは、アプリケーションが明示的にデーモンのステータスを解除しない限り、Executor モードではトラッキングされません。
ノードのプロパティ
次の表に、Executor ベースのインストゥルメンテーション方式に固有のノードプロパティ、または Constructor ベースのインストゥルメンテーション方式（デフォルト）とは異なる動作をするノードプロパティを示します。
プロパティ | [デフォルト値（Default value）] | 説明 |
|---|
プロパティ | [デフォルト値（Default value）] | 説明 |
|---|
thread-correlation-classes
| none | これらのプロパティは、Executor モードで Constructor モードと同様の効果がありますが、特にスレッドトラッキングのコストを制限するために使用する場合は、Executor モードで使用することはお勧めしません。非同期ハンドオフの実装が異なるため、Constructor モードでこれらの設定を使用して達成されたパフォーマンスの向上は、Executor モードの初期設定で得られる場合があります。 |
| thread-correlation-classes-exclude |
| min-transaction-stall-threshold-in-seconds | 60 | Executor モードの場合のみ、指定された秒数以上実行しないと、トランザクションの停止はチェックされません。 |
選択されたアクティビティのトランザクションからの除外
非同期フレームワークは、ユーザトランザクションの処理に関連しない低レベルの非同期メカニズムを使用します（たとえば、負荷に応じてスレッドプールが自動的に拡大および縮小したり、フレームワークが初めて使用する自身のスレッドプールを初期化します）。ライフサイクルが個々のアプリケーション トランザクションにバインドされていないため、これらのコンテキストで使用されているスレッドを無視する必要があります。
このような非同期コンポーネント（通常はスレッドやその他の Runnable）の除外を容易にするために、Executor モードは、キャプチャ抑制と呼ばれるメカニズムを提供します。抑制は、app-agent-config.xml の async-config セクションの抑制ルールによって特定のメソッドに関連付けられます。デフォルトで提供されるこのようなルールの次の例を考えてみます。
<job>
<match-class type="matches-class"><name filter-type="EQUALS" filter-value="java.util.concurrent.ThreadPoolExecutor"/></match-class>
<match-method><name filter-type="EQUALS" filter-value="addWorker"/></match-method>
<action type="suppression"/>
</job>
|
java.util.concurrent.ThreadPoolExecutor クラスの addWorker メソッドは、新しいワーカースレッドが作成、開始、プールに追加されるたびに、ThreadPoolExecutor によって呼び出されるプライベートメソッドです。このようなスレッドは、作成時点で個々のトランザクションに直接関連付けられていないため、抑制ルールは、このメソッド内で発生する非同期タスクハンドオフがトランザクションに関連付けられないようにするために使用されます。その後、これらのスレッドによって実行される非同期タスクは、タスクを作成したトランザクションに関連付けられます。
