Click on a probe to display the configuration panel. The following common configuration options are available for each probe:

• Enabled or disabled
  If a probe is disabled, the bytecode instrumentation required by that particular probe will not be performed. Disabling a probe may be useful for trouble-shooting or minimization of overhead. Note that the overhead of a probe that is enabled but not recording is very small.
• Record single events
  Data in the probe events view is only recorded if this option is selected. Recording single events may add noticeable overhead depending on the activities of the profiled application. Other probe views are not affected by this setting. Once the session is running, the events view of each probe also shows a recording button in the tool bar

  This option is not available for the "Class Loaders" probe, where single events are always recorded.

• Annotate into call tree
  Select this option, if you would like to see payload data from the probe hot spots view in the call tree view. In this way, you get additional information in-place when analyzing performance problems in the call tree view. You can deselect this option in order to minimize overhead.

  This option is not available for the "Servlets" and "Class Loaders" probe.

• Servlets
  The servlet probe splits the call tree for different URL invocations, so you can analyze different requests separately. What constitutes a "different" request is governed by the "URL splitting" setting of the servlet probe. By default, only the request path is retained, and all parameters are discarded.

  When you select the option to split the servlet request with scripts, you can click on the "Edit scripts" button to set up one or more scripts that determine how the call tree is split. The  [Add] button shows you a number of pre-defined templates that are useful starting points. For example, the "Split by request URI" script has the same effect as the default mode for URL splitting.

  In reality, there may be certain request parameters that should be retained for URL splitting, such as parameters that do not identify user input, but determine the type of the request. For example, you may have a dispatcher servlet and a parameter "controller" that determines the type of the request. In that case, you would probably like to retain the parameter "controller" and change the script to

      servletRequest.getRequestURI() + "/controller=" + servletRequest.getParameter("controller")

  The script is passed two parameters, first an instance of com.jprofiler.api.agent.ScriptContext that allows you to store data across subsequent requests, and - more importantly - an instance of javax.servlet.http.HttpServletRequest that gives you access to all information regarding the intercepted servlet request.

  When you add a second script, a second splitting level is introduced. For example, the first script could split by session ID, and the second script by request URI. In that way, you could look at the activity generated by a specific user in isolation. At the top, you could add a third script that splits by the context path. This would enable you to analyze multiple deployed web applications separately.

  You can temporarily disable scripts with the "Disable selected" action in the tool bar or in the context menu. This allows you to experiment with multiple scripts without deleting and re-entering the script entries.

  All nodes in the call tree that are created by URL splitting are prefixed with "HTTP:".

• JMS
  Since messages are custom objects, JProfiler does not know how to optimally display messages in the hot spots and event views. By default, a message is only identified via the toString() value of the destination returned by javax.jms.Message#getJMSDestination().

  With the "message resolver script" you can display customized information on your messages. The script receives a parameter "message" which is of type java.lang.Object. This is because the JMS classes may not be available in the profiled JVM, so the JMS probe cannot depend on them. You can cast the message to a subtype of javax.jms.Message, extract the relevant information and return a string that will be displayed in the JProfiler GUI. That string is the basis for the hot spots calculation in the hot spots view.

• RMI
  RMI has two sides, the client side and the server side. You can separately enable recording of client and server calls if you are only interested in one category.

  For server calls, the call tree is split similar to the servlet probe. There are two splitting modes, one that groups all calls from each IP address, and another that also splits for each port. The latter option is useful if you have multiple clients on a single remote machine and you want to separately see those calls in the call tree.