[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