[wildfly-dev] some JMX APIs cannot obtain an MBean that exists

Brian Stansberry brian.stansberry at redhat.com
Thu Dec 14 08:33:30 EST 2017


The "jboss.as:management-root=server" mbean *is* special. It represents the
management resource at address PathAddress.EMPTY_ADDRESS, and hence it has
a PathAddress that can't directly translate to an ObjectName. It has no
key/value pairs, and those are required in an ObjectName. So "
management-root=server" is a special hard coded name.

It doesn't surprise me that there's something broken in the handling of
that corner case. Can you file a WFCORE please? Please include the details
of your queryNames/queryMBeans calls.

Thanks,
Brian


On Thu, Dec 14, 2017 at 4:34 AM, Kabir Khan <kkhan at redhat.com> wrote:

> I have not tried your example, but I have an educated guess for what is
> going on.
>
> We use org.jboss.as.jmx.PluggableMBeanServerBuilder as an implementation
> for javax.management.MBeanServerBuilder which is what creates the
> platform mbean server. The resulting org.jboss.as.jmx.PluggableMBeanServerImpl
> is what allows the JMX subsystem to expose the management api via jmx.
>
> This gets set almost immediately in the boot process in the block at
> https://github.com/jboss-modules/jboss-modules/blob/1.
> x/src/main/java/org/jboss/modules/Main.java#L520.
>
> I would guess that your javaagent ends up calling getPlatformMBeanServer()
> before JBoss Modules has had a chance to do its stuff, and as the platform
> mbean server gets set on the first call to it, you end up with the default
> implementation of it. This will break things for other users wanting to use
> the pluggable mbean server too :)
>
> Some fixes that come to mind:
> - wait until we've had a chance to initialise before calling
> getPlatformMBeanServer() from your agent
> - make sure that the jmx module is on your javaagent's classpath and
> replicate what JBoss Modules does before calling getPlatformMBeanServer.
> For the server org.jboss.as.standalone is used as the boot module, this in
> turn pulls in the org.jboss.as.jmx module, which has the
> META-INF/services/org.jboss.as.jmx.PluggableMBeanServerBuilder file to
> load the proper implementation
>
> Thanks,
>
> Kabir
>
>
>
> > On 13 Dec 2017, at 22:19, John Mazzitelli <mazz at redhat.com> wrote:
> >
> > I'm seeing odd behavior with the JMX API implementation in Wildfly 11.
> >
> > If you grab this Makefile and two .java files I use for testing you can
> see it yourself - just put these in a tmp directory somewhere:
> >
> > wget https://raw.githubusercontent.com/jmazzitelli/test/master/
> javaagent/Makefile
> > wget https://raw.githubusercontent.com/jmazzitelli/test/master/
> javaagent/TestJavaAgent.java
> > wget https://raw.githubusercontent.com/jmazzitelli/test/master/
> javaagent/TestJavaAgentMXBean.java
> >
> > Then just run "make download-wildfly unzip-wildfly compile run" (make
> sure you don't have other WildFly servers running to avoid port conflicts)
> >
> > This runs WF 11 with a -javaagent attached. In the server output, you
> will see this:
> >
> > 16:31:05,290 INFO  [stdout] (Test Java Agent Thread)
> =============================================================
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) FIND INFORMATION
> ABOUT MBEAN: jboss.as:management-root=server
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread)
> =============================================================
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) isRegistered:
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) true
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) getMBeanInfo:
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread)   description: The
> root node of the server-level management model.
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread)   #attributes: 19
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) getAttribute:
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread)
> serverState=reload-required
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) queryNames:
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) []
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) queryMBeans:
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) []
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) queryNames(null,
> null):
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) FOUND IT: jboss.as:
> management-root=server
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread)
> =============================================================
> >
> > You will see SOME JMX APIs can see the MBean "jboss.as:management-root=
> server",
> > but queryMBeans and queryNames canNOT (note the empty arrays []).
> >
> > But notice getMBeanInfo CAN see it - I can even get the serverState
> attribute value from that (you can see it is in reload-required state - I
> see the same behavior even if it was in "running" state).
> >
> > But again, queryMBeans returns nothing.
> >
> > Oddly, queryNames(null, null) DOES return it in the list (see the "FOUND
> IT" line). It is only if I specifically ask for it does it fail in the
> query API.
> >
> > Finally, note that it seems this MBean "jboss.as:management-root=server"
> is special - because it is specifically broke - if i switch to querying for
> "jboss.as:subsystem=transactions" it all works fine, even the query APIs:
> >
> > 17:16:39,541 INFO  [stdout] (Test Java Agent Thread) queryNames:
> > 17:16:39,541 INFO  [stdout] (Test Java Agent Thread) [jboss.as:
> subsystem=transactions]
> > 17:16:39,541 INFO  [stdout] (Test Java Agent Thread) queryMBeans:
> > 17:16:39,541 INFO  [stdout] (Test Java Agent Thread)
> [org.jboss.as.controller.ModelController[jboss.as:subsystem=transactions]]
> >
> > This problem was seen by others as well (with the same MBean I'm trying
> to get) - see:
> >
> > https://github.com/prometheus/jmx_exporter/issues/89
> >
> > The person there claims queryNames is broke but queryMBeans is OK - that
> does not work in my example either. Neither query API works.
> >
> > I searched JIRA, found nothing related to this MBean not being queryable.
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171214/a163e884/attachment.html 


More information about the wildfly-dev mailing list