[BZ 703557] jmx plugin: auto-discover JVMs not exposed via JMX Remoting

Ian Springer ian.springer at redhat.com
Wed Jan 4 20:48:01 UTC 2012


The jmx plugin is currently only able to auto-discover JVMs that expose 
JMX Remoting. However, it is possible to discover and manage other JVMs 
using the Sun Attach API, with a couple conditions:

1) a Sun JDK (not JRE) or another JDK whose tools.jar contains the Sun 
Attach API (com.sun.tools.attach.*) classes (IcedTea?) is available on 
the Agent box

2) the user the Agent is running as has permission to connect to the JVM 
processes using IPC - typically this means either the Agent is running 
as the same user the JVM is running as, or the Agent is running as root

Even considering these conditions, enhancing the jmx plugin to support 
discovering and managing non-JMX-remoted JVMs would be a useful feature 
that many RHQ users could take advantage of.

I have begun implementing this feature using the patch a community 
member attached to 703557 as a starting point. It is coming along well, 
but there have been a few technical challenges:

1) if the Agent is not running on a Sun, or Sun compatible, JDK (not 
JRE), then the tools.jar containing the Sun Attach APIs will not be 
available, and we cannot bundle the tools.jar with the Agent or the jmx 
plugin, because Sun/Oracle's license does not permit it; therefore, my 
plan is to include tools.jar from the Agent's JDK in the plugin 
container classloader if possible, and if not to log an informative 
warning, e.g. "The Oracle/Sun JDK tools.jar could not be added to the 
plugin container classloader. Plugin functionality that requires classes 
from tools.jar will not be available."

2) I started out trying to load tools.jar into a URLClassLoader created 
by the jmx plugin as needed, but apparently tools.jar can only be loaded 
into a single classloader in the Agent JVM, since it makes use of native 
shared libraries, which cannot be accessed from multiple classloaders; 
so I am instead going to include tools.jar in the plugin container 
classloader, where it will be loaded a single time if it's available, 
and then can be used by the jmx plugin or other plugins; again, we 
cannot bundle the tools.jar with the jmx plugin due to licensing 
restrictions, and we cannot include it in a connection/Resource 
classloader, since there would be one of those per JVM Resource

3) the pid cannot be used as the JVM Resource's Resource key, since it 
will change after the JVM is restarted, the attach API local connector 
address for the JVM also cannot be used, since that will also change 
after a JVM restart. since we are really only interested in monitoring 
long-running "server" JVMs, I think a good choice for the Resource key 
is the set of network addresses the JVM is listening on (e.g. 
"[tcp:0.0.0.0:8080,tcp:0.0.0.0:8443]"), since this is not something that 
will typically change for a given server JVM; the patch from the 
community member looked for the Java system property "app.name" on the 
JVM command line and used that as the Resource key; I didn't go with 
that approach since it requires updating a server's command arguments 
and restarting it in order for RHQ to be able to discover it; I'm 
interested in any other ideas people have for the Resource key

Thanks for any feedback.

--Ian



More information about the rhq-devel mailing list