[BZ 703557] jmx plugin: auto-discover JVMs not exposed via JMX Remoting
Ian Springer
ian.springer at redhat.com
Wed Jan 4 22:22:39 UTC 2012
Alan,
Thanks for the feedback. My responses are inline below.
On 01/04/2012 04:37 PM, Alan Santos wrote:
> Hi Ian - a few questions below.
>
> Is the expectation that these would be manually added or every java process is automatically discovered?
They would be auto-discovered, but I forgot to mention that I only
auto-discover java procs that appear to be servers. Specifically, any
process listening on one or more TCP or UDP ports is considered to be a
server. This prevents java processes for tools and other GUI
applications (e.g. IntelliJ, Eclipse, DBVis) from being discovered.
>
>> 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;
> I assume that we could - technically speaking - push it out from the server?
I assume you mean the RHQ Server. Yeah, that would technically be
possible. However, like the Agent, the Server does not require a JDK (it
can run fine on a JRE), so there's no guarantee the Server will have it
either.
Another possibility would be to use the tools.jars from the managed JVMs
if they happen to be JDKs. However, we can't load tools.jar on a
per-managed-server basis due to the issue with not being able to access
the native libraries tools.jar uses from multiple classloaders [1].
If the user does not want to run the Agent on a JDK, the easiest
alternative would be to let them specify the location of tools.jar via a
system property as a fallback (e.g.
-Dorg.rhq.jdkToolsJar=/opt/jdk1.6.0_30/lib/tools.jar).
[1] Here's an example of the native library error:
java.lang.UnsatisfiedLinkError: Native Library
/usr/java/jdk1.6.0_29/jre/lib/amd64/libattach.so already loaded in
another classloader
>
> I assume that's compliant, but don't know if it's feasible. My strong preference is to *not* requiring a JDK.
Well, we'd only require a JDK for this feature. If a JDK could not be
found, we'd gracefully log a warning.
>
>
>> 3) ...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]");
>> 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'm interested in any other ideas people have for the Resource key
> Not sure I follow how you'll figure out what addresses the JVM is listening on and system properties *could* be set programmatically (preventing the need for a restart).
I can figure out the JVM listen addresses for each discovered java
process using SIGAR. I already have that code written. True, the system
property could be set at runtime. The main advantage of using the set of
listen addresses is that no instrumentation of the managed servers would
be required.
>
> Regardless, what about a multi-tiered approach - looking for a system property and falling back to a formula if not found?
Yes, I was actually considering doing this. I'd probably name the system
property something like "org.rhq.resourceKey", rather than "app.name"
though.
Thanks for the feedback.
>
>
>
> -alan
>
> _______________________________________________
> 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