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

Charles Crouch ccrouch at redhat.com
Wed Jan 25 23:49:45 UTC 2012


Can this feature be leveraged by the AS4/5 plugins so that they can connect to AS instances without having to connect over the jmx-remote port and specify username/password? Obviously the agent process would have to have sufficient privileges to use the attach api to connect to the AS instance in the first place.

Cheers
Charles

----- Original Message -----
> 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
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
> 


More information about the rhq-devel mailing list