Request Tracking

Request tracking connects call sites with execution sites in asynchronous execution flows by adding hyperlinks into the call tree view. For an explanation of the underlying concepts, please see the corresponding help topic.

Request tracking can be changed with the tool bar button or via the [Request Tracking] button in the startup dialog. In the latter case, the selected request tracking settings are active immediately after JProfiler connects to the profiled JVM.

In the request tracking dialog you can switch request tracking on and off separately for the following supported request tracking types:

Executors

The call site is the last profiled method before a task is handed off to an executor service from the java.util.concurrent package. The execution site is in the thread that executes the task.

For example, if you call
```
  Executors.newSingleThreadExecutor().submit(new Runnable() {
      public void run() {
          // your code
      }
  });
```
the enclosing method that calls submit is the call site, and the code below // your code is the execution site.

Executors are used by many higher-level libraries for managing asynchronous executions, those libraries are implicitly supported by this request tracking type.
AWT

The call site is last profiled method before a deferred action is posted to the AWT event queue with EventQueue.invokeLater(...) or similar. The execution site is always in the event dispatch thread.

For example, if you call
```
  EventQueue.invokeLater(new Runnable() {
      public void run() {
          // your code
      }
  });
```
the enclosing method that calls invokeLater is the call site, and the code below // your code is the execution site.

Together with the default entry in the exceptional method configuration, this feature provides a way to comprehensively analyze long-running AWT events.
SWT

The call site is the last profiled method before a deferred action is posted on the UI thread with Display.getDefault().asyncExec(...) or similar. The execution site is always in the UI thread.

For example, if you call
```
  Display.getDefault().asyncExec(new Runnable() {
      public void run() {
          // your code
      }
  });
          
```
the enclosing method that calls asyncExec is the call site, and the code below // your code is the execution site.
Thread start

The call site is the last profiled method before Thread.start() is called. The execution site is a a top-level node in the started thread. If multiple threads are merged, each recorded execution site is still displayed separately.

For example, if you call
```
  new Thread() {
      public void run() {
          // your code
      }
  }.start();
```
the enclosing method that calls start is the call site, and the code below // your code is the execution site.

Request tracking for threads can add a lot of nodes into your call trees that may be hard to interpret, because threads are started by the JRE in ways that are not immediately obvious. It is recommended to use thread start request tracking only in the case of a related problem.

Since the call tree can merge several invocation of a method, one call site can be related to several execution sites, for example an executor invocation can use different threads in a thread pool for different invocations. In this case, the execution site dialog is shown which allows you select the desired execution site. by looking at the displayed thread names and back traces. Call sites are assigned numeric IDs by JProfiler starting with #1, so you can recognize the same call site when browsing call trees for different threads.

On the other hand, a execution site can only by called by a single call site. A hyperlink that leads to the call site is shown in the tree. If more than one call site start a task in the same call stack, multiple execution sites are created side by side.

When jumping between call sites and execution sites, the call tree history is useful to move back and forth in your selection history. This is a general feature of the call tree view which also works for changes in thread, thread status and aggregation level selection.

Note that following a hyperlink will select the explicit thread of the call site or execution site. If you're starting in the "All threads" thread selection, the call tree will always change to that of a single thread. You can subsequently choose the parent thread group or "All threads" again and the current selection will be preserved.