Because when it comes to java, you can never have enough diagnostics

Trying to track down what may be a memory leak in a Java app, or just some really awful misconfiguration by me. On good advice I’ve now added jmxremote everywhere.

In its most bare bones implementation, jmxremote gets enabled by adding the following to your JAVA_OPTS:

-Dcom.sun.management.jmxremote

This will let you launch jconsole and other tools in a local X session (we usually use VNC to remote onto a box and launch jconsole from there) to get a good look inside a running JVM.

To access from a remote workstation or server, add the following as well:

-Dcom.sun.management.jmxremote.port=1099
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Djava.rmi.server.hostname=myhost.example.com

Of course the above lines would be set out on the same line, separated only by a single whitespace between each term. The port shown is just for demonstration purposes, any free port above 1000 will do. The last line is actually very important on Linux systems, as Java sometimes gets confused about its home address (people often have trouble when things try to connect via the lo interface, rather than one with an actual, routable, IP address).

This entry was posted in System Administration, Systems Analysis on by .

About phil

My name is Phil Lembo. In my day job I’m an enterprise IT architect for a leading distribution and services company. The rest of my time I try to maintain a semi-normal family life in the suburbs of Raleigh, NC. E-mail me at philipATlembobrothersDOTcom. The opinions expressed here are entirely my own and not those of my employers, past, present or future (except where I quote others, who will need to accept responsibility for their own rants).