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.

For remote tracking types, the hyperlink leads into a different JVM. That JVM must be profiled at the time of the remote call and it must be open in a separate JProfiler window. JProfiler will activate that window and show the corresponding execution site in the call tree.

Remote tracking works with live sessions as well as snapshots. For execution sites that are called from a remote VM, JProfiler adds a VM ID to the execution site node in the call tree. Internally, that VM ID is a UUID, but to make it easier to interpret, JProfiler translates it to a small number, starting at #1. While the JProfiler GUI is open, that number remains unique. After a restart, the VM ID may be different, depending on the order in which the VMs are opened.

For easier orientation, the VM ID is displayed in the status bar. This ID does not only help you in remote tracking scenarios, it is also useful to know if two snapshots were taken from the same VM run.

For remote call sites, JProfiler always adds a hyperlink to the call tree because it cannot know if the call is also profiled on the remote site. If you click on such a link without having the corresponding remote VM open in JProfiler, you will get a warning message.

In principle, a remote call site or execution site could be available in multiple windows. This would happen if you open multiple snapshots from the remote VM at the same time. In that case, JProfiler shows a dialog requiring you to select a target window for the hyperlink when you click on it.

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.
RMI
The call site is the origin of the RMI call, the execution site is where the server handles the call. Both the client as well as the server VM must be profiled and opened in JProfiler, either live or as a snapshot.
Multiple RMI calls may be handled by different threads on the remote side, each of which will create its own execution site for the call.
Remote EJB
The call site is the origin of the remote EJB call, the execution site is in the implementation in the EJB server. Both the client as well as the server VM must be profiled and opened in JProfiler, either live or as a snapshot. JBoss 7.1+ and Weblogic 11+ are supported for remote EJB tracking.
Multiple remote EJB calls may be handled by different threads on the remote side, each of which will create its own execution site for the call.
Web services
The call site is where the web service call is made, the execution site is where the server handles the call. Both the client as well as the server VM must be profiled and opened in JProfiler, either live or as a snapshot. The same web service implementations as for the web service probe are supported.
Multiple web service calls may be handled by different threads on the remote side, each of which will create its own execution site for the call.

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. The history always remains within the same window and does not follow remote calls.

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.