The Executor mode is an Experimental Feature. It is an early iteration of a generally available product feature. That means it may not be entirely feature complete, but it is generally available, fully supported by AppDynamics in accordance with your relevant support agreement(s), production-ready, and available for use via end user opt-in. If you have any questions of feedback about this Experimental Feature, reach out to your AppDynamics account team.

When the agent is in Executor Mode, transaction activity is tracked from thread to thread by instrumenting Executor.execute() and similar method(s) such that the agent can identify application work to track as that work is being scheduled.

Benefits

  • Reduces the agent's resource consumption for most use-cases
  • Enables tracking thread hand-offs using the new agent API
  • Improves reliability of last thread on tier asynchronous transaction demarcation
  • Allows Service Endpoints to measure response time of services implemented using asynchronous frameworks

Behavior of Service Endpoints in Executor Mode

The behavior of Service Endpoints differs between Constructor and Executor Modes. In constructor mode, each asynchronous transaction segment is represented by its own Service Endpoint, and the Service Endpoint corresponding to the transaction entry point shows the execution time of the initiating thread as shown below.

With the executor instrumentation strategy, metrics for a single Service Endpoint are reported, with a response time corresponding to the execution time of the the entire asynchronous transaction as shown below. 

Currently, each service entry point must match a transaction entry point. Configuration of Service Endpoints at other points within execution of asynchronous transactions is currently not supported in the Executor Mode. Additionally, Service Endpoints only report if placed within the context of an executing a Business Transaction when the agent is in Executor Mode.

Support for Raw Threads

Support for raw threads differs between executor and constructor modes. While constructor mode supports tracking of all threads created in the context of a transaction, the Executor Mode supports only non-daemon threads which are started in the context of a transaction. The daemon status is inherited from the parent thread which can cause unexpected results. For example, the worker threads in an application server are often daemon threads, so any thread started directly within servlet code is not tracked in the Executor Mode unless the application explicitly unsets its daemon status.

Node Properties

The following table presents the node properties which are specific for the executor-based instrumentation strategy, or which work differently than for the constructor-based instrumentation strategy (default).

Property

Default value

Description

thread-correlation-classes


none

These properties have the same effect in Executor Mode as in Constructor mode, however their use is discouraged in Executor Mode, especially when used to limit the costs of thread tracking. Due to the differences in implementation of the async hand-offs, any performance gains achieved using these settings in constructor mode are likely to be available using the out of the box settings in Executor Mode.
thread-correlation-classes-exclude
min-transaction-stall-threshold-in-seconds60For Executor Mode only, the transactions will not get checked for stall unless they run at least the specified number of seconds

Excluding Selected Activities from Transactions

Asynchronous frameworks use lower-level asynchronous mechanisms which are not related to the processing of user transactions (for example, a thread pool might grow and shrink automatically, depending on the load or a framework might initialize its thread pool upon the first use). It is necessary to ignore threads used in these contexts since their lifecycle is not bound to any individual application transaction.

To facilitate exclusion of such asynchronous components (usually Threads and other Runnables), executor mode offers a mechanism called capture suppression. The suppression is tied to a specific method by a suppression rule in the async-config section of app-agent-config.xml. Consider the following example of such a rule provided by default:


<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>
XML

The addWorker method on the  java.util.concurrent.ThreadPoolExecutor class is a private method invoked by ThreadPoolExecutor whenever a new worker thread is to be created, started and added to the pool. Since such threads are not directly associated with any individual transaction at the point of creation, a suppression rule is used in order that any asynchronous task hands offs occurring within this method will not get associated with the transaction. Any asynchronous tasks subsequently executed by these threads will be associated with the transaction that created the task.

Known Limitations

Executor mode is introduced in version 4.5.11 as an Experimental Feature. You should validate the behavior of executor mode in instrumented applications prior to production deployment and report any apparent anomalies.