[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