Probe is not showed up in Diagnostics Enterprise interface

Telnet from Diagnostics server to localhost:2612

–If fails, Check /etc/ timemanager.time_source=

–If timemanager.time_source=ntp, check Diagnostics server can access the internet.

Telnet to port 2612 for the Mediator specified in the property “” in probe’s /etc/ file from probe machine.

Try to open probe URL /profiler/metrics?xml=true from the Diagnostics server.

• Check for Firewalls.

• Check if there is a proxy specified or needed.

• Try changing /etc/

• Try starting probe with -Dhttp.nonProxyHosts=<fully qualified name of the Diagnostics server>

How to change capture class map setting manually in diagnostics probe

To disable capture class map open file in <probe_install>/etc. Look for When capture class map is enabled it is set to true and will look like If you want to disable it and put things back to their default state, change the entry to

How to enable Cross VM on probes

Enable Corba cross-VM on both probes. In diagnostics 8.x we added cross-VM support for pure IIOP which covers RMI over IIOP as well.

Enable Corba Cross-VM by following the steps below on both the probes:

a) Disable RMI in the points file in auto_detect.points file ([RMI] active = false)

b) Enable the Corba points (there is a Corba section towards the end of the auto_detect.points file)

c) Read the documentation under [Corba cross-VM Documentation] section of the points file and follow ALL the steps listed there.

d) After doing all of the above, the "jvmEntries" should look something like below.



No data is displayed for “IBM WebSphere” monitors in the Diagnostics tab

LoadRunner: 9.52 running on Windows 2003, HP Diagnostics: Version 8.0, WebSphere Commerce: 6.x on AIX.

Retrieving data for the "Stand Views" graphs in diagnostics is working fine, but nothing is displayed for the "IBM WebSphere" views.

Java 2 Security is NOT enabled. The HP Diagnostics Performance Monitoring Infrastructure (PMI) statistic sets are selected as Extended.

Checking the probe.log on the AIX machined shows the following WARN log:

2010-05-06 10:20:09,836 WARN com.mercury.diagnostics.capture.metrics [Metrics Collection] Error initializing com.mercury.diagnostics.capture.metrics.jmx.JMXCollector@ca1f548

java.lang.IllegalAccessError: com.mercury.diagnostics.capture.metrics.jmx.JMXCollector tried to access method com/mercury/diagnostics/capture/metrics/jmx/JMXCollector$AttributesAndDescriptors.add(Ljava/lang/String;Lcom/mercury/diagnostics/common/metrics/MetricDescriptor;)V

Invalid classpath configuration on the IBM Websphere – HP Diagnositcs boot loader on the AIX machine.

Check the Boot Classpath configuration in the WebSphere Admin Console and ensure it has all the correct entries.

In this case it should have read:



but it did not have the first entry (1.4.2__1)

How can a probe (Java Agent) be bound to a specific network interface (NIC)

If the Diagnostics Java Agent (probe) is installed on a server that has multiple network interfaces (NIC) and there is a requirement to ensure that all network communications between the probe and its Mediator server occurs via a specific NIC

To bind the Java Agent (probe) to a specific network interface, edit the probe configuration file:


and specify the host address the probe is to bind to using:

# Host address to bind to. Uncomment this and specify an IP address if

# the SUT has multiple interfaces, and only one should be responding to

# HTTP requests. =

Restart the probe to apply the new configuration.

Exception Signal 11 while starting Java probe with the WebSphere

Immediately upon starting the WebSphere application server with Diagnostics Probe, the JVM crashes. In the dump file from the crash, if "Exception Signal 11" is observed in WebSphere logs.


JVMDG217: Dump Handler is Processing Signal 11 – Please Wait.

JVMDG303: JVM Requesting Java core file

JVMDG304: Java core file written to /opt/WebSphere/AppServer/javacore.20101129.161814.22608.txt

JVMDG215: Dump Handler has Processed Exception Signal 11.

"signal 11 received" is seen in java core dump logs too.

Process level CPU usage metrics are not supported in probe for Linux 1.4.2 core, and though the probe should detect this initially, in some cases this didn’t happen.

Comment out the following metrics in etc/metrics.config file and restart the application/probe again:


ProcessMetrics/processCpuUtilAbs = ProcessCpuUtilAbs|percent|Probe

Error: “RoleBasedAuth E SECJ0306E: No received or invocation credential exist on the thread. The Role based authorization check …”

When using the Diagnostics 8.04 Java Agent to probe a WebSphere 6.1 Application Server (WAS), if the following error messages are repeatedly written to the WAS SystemOut.log:

[3/19/11 18:35:09:625 CET] 00000028 RoleBasedAuth E SECJ0306E: No received or invocation credential exist on the thread. The Role based authorization check will not have an accessId of the caller to check. The parameters are: access check method getState on resource Server and module Server. The stack trace is java.lang.Exception: Invocation and received credentials are both null









at com.mercury.diagnostics.capture.metrics.jmx.WebSphereJMXCollector.isStartupCompleted(

at com.mercury.diagnostics.capture.metrics.jmx.WebSphereJMXCollector.doInitialize(

at com.mercury.diagnostics.capture.metrics.jmx.JMXCollector.initialize(

at com.mercury.diagnostics.capture.metrics.CollectorControl.initialize(

at com.mercury.diagnostics.capture.metrics.CollectorAgent.validateInitialization(




[3/19/11 18:35:09:633 CET] 00000028 RoleBasedAuth A SECJ0305I: The role-based authorization check failed for admin-authz operation Server:getState. The user UNAUTHENTICATED (unique ID: unauthenticated) was not granted any of the following required roles: adminsecuritymanager, operator, iscadmins, deployer, administrator, monitor, configurator.

[3/19/11 18:35:09:695 CET] 00000028 ServiceLogger I initialize FFDC0009I: FFDC opened incident stream file /prod/IBM/websphere61/AppServer/profiles/mpeprodmpeasp06/logs/ffdc/ap1ga0f1_00000028_11.03.19_18.35.09_0.txt

[3/19/11 18:35:09:711 CET] 00000028 ServiceLogger I resetIncidentStream FFDC0010I: FFDC closed incident stream file /prod/IBM/websphere61/AppServer/profiles/mpeprodmpeasp06/logs/ffdc/ap1ga0f1_00000028_11.03.19_18.35.09_0.txt

[3/19/11 18:35:09:771 CET] 00000028 ServiceLogger I open FFDC0009I: FFDC opened incident stream file /prod/IBM/websphere61/AppServer/profiles/mpeprodmpeasp06/logs/ffdc/ap1ga0f1_00000028_11.03.19_18.35.09_1.txt

[3/19/11 18:35:09:787 CET] 00000028 ServiceLogger I resetIncidentStream FFDC0010I: FFDC closed incident stream file /prod/IBM/websphere61/AppServer/profiles/mpeprodmpeasp06/logs/ffdc/ap1ga0f1_00000028_11.03.19_18.35.09_1.txt

WebSphere 6.1 uses role-based security to protect access to the MBeanServer when administrative security is ‘on’. This causes security exceptions when the Diagnostics JMX collectors access the MBeanServer. A workaround for this issue is included in the Diagnostics WebSphere6JMXCollector. However, when the Diagnostics Java Agent runs with WAS 6.1, both the Diagnostics WebSphere5JMXCollector and WebSphere6JMXCollector find the same WAS MBeanServer instance. The errors are reported as the WebSphere5JMXCollector does not include the required workaround.

To remove this error, modify the file "metrics.config" in the probe configuration "/etc" directory and either comment out or remove the metrics entries for the WebSphere V5.x Collector, that is, comment/delete all entries beginning with "WebSphere5" for instance:

WebSphere5/beanModule.creates = EJB Creates|count|EJB

Diagnostics Commander jetty.log shows several out of threads error message

If there are several "OUT OF THREADS" and "LOW ON THREADS" messages in the Commander jetty.log file and increasing jetty.threads.max from 200 to 600 in the file also does not resolve the problem, the reason is because there is not enough connections for the amount of probes. Each mediator needs 40 connections per probe plus 40.

Steps to take for the out of threads issue on the Diagnostics Commander Server:

• Edit the file "<MercuryDiagnostics_Install>\Server\etc\" and set:


• Stop the Diagnostics application running on Diagnostics commander server,

• Edit the file "<MercuryDiagnostics_Install>\Server\nanny\windows\dat\nanny\server.nanny" and replace the line:

start_nt=<MercuryDiagnostics_Install>\Server\jre\bin\javaw.exe^ -server -Xmx1200m "-javaagent:<MercuryDiagnostics_Install>\Server\probe\lib\probeagent.jar" -classpath "<MercuryDiagnostics_Install>\Server\lib\mediator.jar;<MercuryDiagnostics_Install>\Server\lib\loading.jar;<MercuryDiagnostics_Install>\Server\lib\common.jar;<MercuryDiagnostics_Install>\Server\lib\mercury_picocontainer-1.1.jar" com.mercury.opal.mediator.util.DiagnosticsServer


start_nt=<MercuryDiagnostics_Install>\Server\jre\bin\javaw.exe^ -server -Xmx1024m -Xms1024m -XX:MaxNewSize=448m -XX:NewSize=448m -XX:SurvivorRatio=6 "-javaagent:<MercuryDiagnostics_Install>\Server\probe\lib\probeagent.jar" -classpath "<MercuryDiagnostics_Install>\Server\lib\mediator.jar;<MercuryDiagnostics_Install>\Server\lib\loading.jar;<MercuryDiagnostics_Install>\Server\lib\common.jar;<MercuryDiagnostics_Install>\Server\lib\mercury_picocontainer-1.1.jar" com.mercury.opal.mediator.util.DiagnosticsServer

• Start the Diagnostics application on Diagnostics commander server.

Where "<MercuryDiagnostics_Install>" is, for example, "E:\MercuryDiagnostics".

Diagnostic support on VMware

It should be possible to install the Diagnostic Server on a VMware if the machine’s MAC address is static.

Diagnostics server’s license depends on the MAC address which by default is dynamic on a VMware. Please contact your system administrator to perform the necessary adjustments to make the VMware MAC address static. The following VMware knowledge base article describes how to do so:

The installation of the Mediator component should not be a problem from a licensing point of view as Diagnostic license uses the Diagnostic Server’s MAC address and not the Mediator’s MAC address.

Connection Failure: The connection to the named instance has failed

Connection Failure: The connection to the named instance has failed. Error: Receive timed out. The error occurs when we specify a named Instance for SQL collector in sqlserver-config.xml

The presence of the instanceName is failing to connect to the Database because of a bug in the JDBC driver.

The issue is fixed with Diagnostics 8.03 and above