| Documentation Contents |
The problem is most likely that your default Windows temporary directory is on a FAT file system. If your TMP file system is NTFS and JConsole does not show your processes, check your username as described in FAQ #2.
For security reasons, local monitoring and management is only supported if your default Windows temporary directory is on a file system that supports setting permissions on files and directories (for example, on an NTFS file system). It is not supported on a FAT file system that provide insufficient access controls.
A potential workaround for this issue:
Set the TMP environment variable to refer to a directory on an NTFS
file system, or any file system that supports setting permissions
on files and directories before you run your application with local
or remote management enabled. Note that this file system should be
local to the machine. Setting this option for target applications
is application specific. To set this variable in a command prompt
or in a batch script, simply enter the following:
set TMP=path
The environment variable can be set globally by adding it to the list of environment variables in the System Properties (Control Panel->System, select the "Advanced" tab and click on the "Environment Variables" button). Through this interface, you can choose to set the variable for all processes run by the current user or globally as a system variable for all processes run by the system.
It is a known problem in JDK 5 that jconsole and jps commands do not work on Windows if your username contains '_' (underscore). Bug 6301562 will be fixed in a future release.
Please see the "How to secure a password file on Windows systems" document for details.
It is most likely a configuration problem. First, make sure your application was started with remote management enabled. (See details from the "Monitoring and Management using JMX" document.) Second, check if SSL is enabled in the management properties to enable remote management and if it is configured properly.
SSL is enabled by default when the remote management is enabled. You can disable SSL by setting com.sun.management.jmxremote.ssl property to false. If your application is not set up with SSL properly but SSL is enabled for remote management, JConsole will fail to connect to the application. Please see "Using SSL" section in the "Monitoring and Management Using JMX" document for information about using SSL for remote management.
If the connection failure problem occurs only when your application runs on Linux, please see FAQ #5.
This is most likely a configuration problem on the Linux machine or the management properties specified to run the application. Please also see FAQ #4 about using SSL.
You should check the following:
Run "hostname -i" command. If it reports 127.0.0.1, JConsole would not be able to connect to the JVM running on that Linux machine. To fix this issue, edit /etc/hosts so that the hostname resolves to the host address.
Packet filtering is built in the Linux kernel. You can run "/sbin/iptables --list" to determine if an external client is allowed to connect to the JMX agent created for remote management. You can use the following command to add a rule to allow an external client such as JConsole to connect:
/usr/sbin/iptables -I INPUT -s jconsole-host -p tcp --destination-port jmxremote-port -j ACCEPT
where jconsole-host is either the hostname or the host address on which JConsole runs on and jmxremote-port is the port number set for com.sun.management.jmxremote.port for remote management.
When you enable the application for remote management with SSL, you have set up a digital certificate on the system where the JMX agent (MBean server) is running and configured SSL properly.
Assuming you created a keystore as described in the JSSE Guide and started your application (Server) as follows:
% java -Djavax.net.ssl.keyStore=keystore \
-Djavax.net.ssl.keyStorePassword=password Server
To connect to this application, you need to run jconsole as follows:
The above configuration authenticates the server only. If client authentication is set up, you will need to provide a similar keystore for the JConsole's keys, and an appropriate truststore for the application.% jconsole -J-Djavax.net.ssl.trustStore=truststore \
-J-Djavax.net.ssl.trustStorePassword=trustword
The com.sun.management.jmxremote.port management property specifies the port where the RMI Registry can be reached but the ports where the RMIServer and RMIConnection remote objects are exported is chosen by the RMI stack. To export the remote objects (RMIServer and RMIConnection) on a given port you need to create your own RMI connector server programmatically, as described in the section Mimicking Out-of-the-Box Management Using the JMX Remote API in the Java SE Monitoring and Management Guide. You must specify the JMXServiceURL as follows:
JMXServiceURL url = new JMXServiceURL("service:jmx:rmi://localhost:" + port1 + "/jndi/rmi://localhost:" + port2 + "/jmxrmi");In the command above, port1 is the port number on which the RMIServer and RMIConnection remote objects are exported and port2 is the port number of the RMI Registry.
The standard MIB for the Java virtual machine can be found at: http://java.sun.com/j2se/1.5.0/docs/guide/management/JVM-MANAGEMENT-MIB.mib. Some objects exposed in the JVM MIB are 64-bit quantities. To see these objects, you need to use the SNMP v2 protocol. If you can walk the JVM MIB using SNMP v1 protocol, the 64-bit objects are skipped.
The JVM MIB includes 64-bit objects which require to use the SNMP v2 protocol. All the 64-bit objects are skipped if you walk the JVM MIB using SNMP v1.
Copyright © 1993, 2011, Oracle and/or its affiliates. All rights reserved. Please send comments using this Feedback page. |
 Java Technology |