Tunneling JMX in the 7u4 JDK

JMX is quite commonly used by various Java tools, such as Java Mission Control, JConsole and JVisualVM, to provide monitoring and management capabilities of the Java runtime and applications running in the JVM. The protocol most commonly used behind the scenes is JMX over RMI. It requires an RMI registry to be running, from which a stub for communicating with the RMI server can be looked up by the client. The RMI registry is running on well known port. For JRockit it was 7091 by default. For Hotspot it must be specified using a system property. The port for the RMI server, which is returned in the stub retrieved from the registry, is however anonymous by default. This makes tunneling traffic pretty cumbersome.

Now, one handy but often overlooked feature that entered the 7u4 JDK as part of the JRockit convergence, was the ability to specify the port of the RMI server. By setting the port used by the RMI registry and the RMI server to the same port, tunneling will be much easier. Now, the name of the property for setting the port of the RMI Server was slightly changed from the JRockit implementation, and is now called com.sun.management.jmxremote.rmi.port, instead of com.sun.management.rmiserver.port. Here is an example of how to enable the external management agent with the same RMI registry and RMI server port on the command line, in JDK 7u4 and later:

java -Dcom.sun.management.jmxremote.port=7091 -Dcom.sun.management.jmxremote.rmi.port=7091 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

One could argue that better names for the properties would have been rmi.server.port and rmi.registry.port.

With some luck we will get startup flags similar to JRockit’s into Hotspot in the future. It is all too easy to get one of the system properties wrong, and there is no way you can tell for sure. The parameters are not validated. In JRockit the same command line as above would have been:

java –Xmanagement:port=7091,rmiserver.port=7091,ssl=false,authenticate=false

IMHO it makes much more sense to let the directive to tell the JVM to start a management agent be a startup flag, rather than a set of arbitrary system properties. Not to mention getting some of that sweet validation of the parameters.