|
The following built-in probes have particular configuration options:
-
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.
For debugging purposes it may be useful to show the full URL in the events view regardless of how the URL
splitting is considered. Check the "Show full URLs in events" in this case.
-
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.
|