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