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

Ian Springer ian.springer at redhat.com
Fri Jan 6 16:08:47 UTC 2012


Yes, it will work; I peeked inside the tools.jar that comes with F15's 
openjdk6, and it contained the com.sun attach API classes. It will 
presumably also work on HP-UX, since the HP-UX JDK is based on the Sun 
JDK. As for AIX, making it work there would be some extra work, since 
the IBM JDK includes a com.ibm equivalent of the Attach API. I have no 
idea about the Mac OS X JDK.

On 01/05/2012 05:58 PM, Charles Crouch wrote:
> So did we ever determine if this approach would work with OpenJDK jdks?
>
> Cheers
> Charles
>
> ----- Original Message -----
>> 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
>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/rhq-devel
>>
>>
>>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel


-- 
Ian Springer
Principal Software Developer
JBoss Operations Network
Red Hat
ian.springer at redhat.com



More information about the rhq-devel mailing list