Foglight for Java EE Technologies 5.9.11

The RemoteInvocationLimit determines the maximum number of calls that the Java EE agent follows from a single method to a remote system. Beyond this number, the Java EE agent only collects and aggregates overall performance information for the remote system invocations. This is done for two reasons:

•

A large number calls to remote systems from a single method is highly likely to produce a performance problem.

•

It is expensive for the Nexus to process Tag and Follow™ information for a large number of remote invocations on a single request.

The default value is 10. If this limit is exceeded, the Java EE agent logs a WARN message that identifies the method where the remote invocations are taking place.

If you are receiving WARN log messages and you require more detail on the remote invocations, you can increase this setting.


	IMPORTANT: Increasing this value also increases the amount of CPU and memory that the Nexus uses.

Decrease this value if you are receiving the WARN log messages, but the Nexus is exhibiting symptoms of excessive memory use.


	NOTE: This setting is only valid for FullDetail, ComponentDetail and BasicDetail Instrumentation Levels. Changing its value has no effect if the Instrumentation Level is NoDetail. For more information about setting instrumentation levels, see Configuring instrumented simple method settings .

To set the request remote invocation limit:


	TIP: To review how to access the instrumentation settings editor, see Editing agent instrumentation configurations .

Click the Requests tab of the Edit dialog box.

Type a value in the RemoteInvocationLimit box.

Click Save.

Restart your application server.

Manual configuration — RemoteInvocationLimit

If you manually edit the instrumentation.config file, use the following syntax to specify the remote invocation limit.

RemoteInvocationLimit = 50;

Allowing non-component root nodes

By default, the Java EE agent collects requests that start at a defined component technology (such as HTTP, JMS, RMI, EJB, or Servlet) or a custom component. Enable the AllowNonComponentRootNodes setting to allow the Java EE agent to collect information on requests that start at any method. This may be useful when using the X-Agent or the StopCurrentRequestInMethods configuration setting. For more information, see Separating requests by parent method.

By default, this setting is disabled.


	NOTE: This setting is only valid for the FullDetail instrumentation level. Changing the value has no effect if the instrumentation level is set to ComponentDetail, BasicDetail, or NoDetail. For more information about setting instrumentation levels, see Configuring instrumented simple method settings .

To enable non-component root nodes:


	TIP: To review how to access the instrumentation settings editor, see Editing agent instrumentation configurations .

Click the Requests tab of the Edit dialog box.

Select the check box for AllowNonComponentRootNodes.

Click Save.

Restart your application server.

Manual configuration — AllowNonComponentRootNodes

If you manually edit the instrumentation.config file, use the following syntax to enable non-component root nodes.

AllowNonComponentRootNodes = true;

Separating requests by parent method

Use the StopCurrentRequestInMethods parameter as a separate parameter when you want to stop the request in the configured method. Once stopped, the next method entered starts a new request. The data collected for the original request is not lost but has stopped collecting. The benefit of using the StopCurrentRequestInMethods parameter is to organize and specify the time range during which the Java EE agent collects requests.

The StopCurrentRequestInMethods setting splits one request type into two or more request types where the original request ends on the specified method and new requests are started on children of the specified method.

For example, suppose that you have the following request:

GET /foo/bar -> service() -> doGet() -> doSomeStuff() -> doMoreStuff()

and you want to configure it to split on the doGet() method. The result is two requests:

GET /foo/bar -> service() -> doGet()

doSomeStuff() -> doMoreStuff()

The configured method becomes a leaf in the original request and methods called within the defined method become the root node in new request types. The configured method becomes a method node even if it was previously part of a component.

IMPORTANT: To prevent the split requests from being filtered out, make two additional changes:

•

AllowNonComponentRootNodes must be set to enabled (true).

•

Filtering Rules in the Recording Settings must be updated with a rule to include the new request type.

For more information, see Allowing non-component root nodes , and the Managing Nexus Recording Settings topic in the Managing Application Servers Administration and Configuration Guide.


	NOTE: Methods included in this list should not be included in the Named Methods list, the Custom Components list, the Long Running User Methods list, or the Start New Request In Methods list. This list takes precedence over all others. If the method is included in other lists, the agent logs a warning indicating the affected method and the ignored instrumentor.

To split a request on a parent method:


	TIP: To review how to access the instrumentation settings editor, see Editing agent instrumentation configurations

Click the Requests tab of the Edit dialog box.

To add method that the agent should stop on, click Edit

beside StopCurrentRequestInMethods.

In the Settings Editor that opens, you can add, remove, or change the order of methods that the agent should stop on.

Click

Add to add a stop method.

In the empty row that appears, do the following:

Leave the Include or Exclude option set to include (the default setting).

This example does not use a regular expression, so leave the Regex check box cleared.

Click in the Method Name box and type the name of the method that you want the agent to stop on. In this example, that is:
com.foo.bar.SomeServletName.doGet()

Click OK.

In the Edit dialog box, click Save.

Restart your application servers.

The result is two requests:

GET /foo/bar -> service() -> doGet()

and

doSomeStuff() -> doMoreStuff()

Manual configuration — StopCurrentRequestInMethods

If you manually edit the instrumentation.config file, use the following syntax to specify the stop methods.

StopCurrentRequestInMethods = MethodList();

For example, if the following request

GET /foo/bar -> service() -> doGet() -> doSomeStuff() -> doMoreStuff()

is configured to split on the doGet() method as follows:

StopCurrentRequestInMethods = MethodList(
include "com.foo.bar.SomeServletName.doGet()",
);

the result will be the following two requests:

GET /foo/bar -> service() -> doGet()

doSomeStuff() -> doMoreStuff()

Splitting requests during single tracing

By default, requests that have been split using the StopCurrentRequestInMethods setting also appear as separate requests when collecting in single-trace mode.

Disabling the SplitRequestsWhenSingleTracing setting prevents request splitting when collecting a single trace. Requests that would otherwise be separated appear as part of the same call tree. In some situations, the additional context may be helpful for more detailed analysis.

To enable non-component root nodes: