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

Charles Crouch ccrouch at redhat.com
Thu Jan 5 22:58:04 UTC 2012


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
> 
> 
> 


More information about the rhq-devel mailing list