Built-in Probes

## Built-in Probes |

| All built-in probes are described on the help page of the probes view. Here, only configuration aspects of built-in probes are discussed. For general information on the concepts behind probes, see the corresponding help topic. 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 on startup If you would like to record probe data right after connecting to the profiled JVM, you can select this option. Otherwise you can start recording data for selected probes manually in the probes view. Record single events Data in the probe events view is only available 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. 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" probe.

| The following built-in probes have particular configuration options: JDBC If required, you can choose to resolve parameters of prepared statements. By default, those parameters are shown as question marks in the hot spot view and the event view. Resolving these parameters makes the hot spots view more cluttered, but can be useful for debugging purposes. JPA/Hibernate The JPA/Hibernate probe supports a number of providers, like Hibernate 3.x, Hibernate 4.x and eclipselink 2.3. You can deselect providers in the probe configuration. 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 spot view. 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. 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". In the text field after the "Retain request parameters" radio button, a comma-separated list of such parameters can be specified. However, the structure of the URLs may be more complex than that. Maybe you want to discard parts of the request path or conditionally retain request parameters. In that case, you can use the "Resolve with script" option and define a script that returns the string defining the URL displayed by JProfiler. The script is passed two parameters: `uri` for the request path and `queryString` for the query parameters. Just returning `uri` would correspond to the default "Request path only" setting.