4 Replies Latest reply on Oct 29, 2014 6:37 AM by Roland Bergler

    getPlatformMBeanServer found wrong server

    JOC Newbie

      I recently had a problem with JBoss AS 7.4.0 and jmx lookusp, where a simple query to the MBean server fails to find something.

      This was running on 64bit Java7  jdk1.7.0_25

       

      The application started up ok, and I attempted to log in, then logincode hits a servlet that checks the http and https ports the server is using.

      The lookup code was as follows, but didn't find anything.

       

           mBeanServer = ManagementFactory.getPlatformMBeanServer();
           query = new ObjectName("jboss.as:socket-binding-group=standard-sockets,socket-binding=http");
           port = (Integer) mBeanServer.getAttribute(query, "boundPort");
      

       

      As I was debugging at the time I hit this problem, I took a look into it.  The mbeanserver the getplatformmbeanserver was returning was com.sun.jmx.mbeanserver.JmxMBeanServer , when looking at a working server this always appears to be org.jboss.as.jmx.PluggableMBeanServerImpl

       

      Dumping out a list of everything in the mbeanserver showed that all our webservices were in there,

      e.g     jboss.ws:context=WebApp,endpoint=CalendarAccessService etc etc

      but none of our other deployed items like ejb's, servlets

       

      There were a variety of other jboss specific items,

      e.g     jboss.modules:type=ModuleLoader,name=LocalModuleLoader-2

       

      and many runtime items

      e.g     java.lang:type=Memory

       

      but there wasn't a single item in there starting with  jboss.as:

       

      It appears to be rather random, I have only had it happen once to me. Some other developers on my team have seen it too, and one of our overseas offices has seen it a few times now.

       

      I'm a little stumped at how / why this might be happening and what I can do to protect against it. One the one time I caught it going wrong, I used findMbeanServer to list everything, but it only returned the one server, so iterating over all servers found doesn't appear to be an option. I cant think what else to try - or how to force the problem to be able to investigate it better, so all suggestions welcome !

       

        • 1. Re: getPlatformMBeanServer found wrong server
          jaikiran pai Master

          I recently had a problem with JBoss AS 7.4.0

          Is that a typo? Which exact version of JBoss AS7 or JBoss EAP or WildFly are you using and where did you get it from?

           

          What command are you using to start the server?

          • 2. Re: Re: getPlatformMBeanServer found wrong server
            JOC Newbie

            Sorry for the confusion - it's JBoss EAP 6.3.0.Alpha1 from the downloads area.  We have only recently managed to move off of JBoss 4.3 and are still ironing out a few kinks at the moment as we have a distinct lack of app server know how here. We were initially using JBoss7.1.2 but it kept stalling during startup, so following advice from the forums we moved up to the latest alpha - but have taken to referring to it by it's other tag in the startup log (7.4.0) for now as it avoids having to endlessly explain the 6 is 7 thing to others untill we get it all worked out.

             

            When I saw this problem happen, I was running from within eclipse using JBossTools (Version: 2.4.101.Final) I never start from cmd locally.

            Program arguments -

            -mp "C:/jboss-eap-6.3.0.Alpha/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b BIS01-0724 --server-config=standalone-V11.8_Workspace-sqlserver.xml "-Dadapt.home=C:/develop/AdaptV11_Workspaces/AdaptV11_Mainline/" "-Dencryption.vault.home=C:\ADAPTV11-JBOSS\encryption"

             

            VM arguments -

            "-Dprogram.name=JBossTools: V11.8 Mainline - JBoss EAP 6.3 Alpha Server" -server -Xms1024m -Xmx1024m -XX:MaxPermSize=256m -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true "-Dorg.jboss.boot.log.file=C:/jboss-eap-6.3.0.Alpha/standalone/log/boot.log" "-Dlogging.configuration=file:/C:/jboss-eap-6.3.0.Alpha/standalone/configuration/logging.properties" "-Djboss.home.dir=C:/jboss-eap-6.3.0.Alpha" -Dorg.jboss.logmanager.nocolor=true

             

            The application is deployed as a single exploded ear (application.xml attached).

             

            We use a slightly modified standalone-full.xml attached

             

            Our US office were starting the server using a simple batchfile that just sets the environment variables above and calls standalone.bat passing it -b <ip address> --server-config=standalone-adapt.xml


            One thing I did notice on the US server logs one time when it went wrong, it looked like the webapp was servicing requests before the server had completed starting up. I'm basing this purely on seeing log output from servlets appearing before this line below which I usually take to mean the server has started up.

             

            10:07:46,973 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss EAP 6.3.0.Alpha1 (AS 7.4.0.Final-redhat-4) started in 74847ms - Started 3253 of 3317 services (120 services are lazy, passive or on-demand)

             

            That might not be relevant, might just be the logger playing catch up, but it is something else I am unable to replicate on my setup. For me no pages get served before the line above appears in the log. I have tried forcing delays in various areas, but cannot get this to happen locally. I am also assuming that the problem the US office see is the same as I saw, but it feels like the same thing.

            Unfortunately I didn't get a copy of the log file before they cleared it all out and restarted the server.

            • 3. Re: getPlatformMBeanServer found wrong server
              jaikiran pai Master

              JOC wrote:

               

              Sorry for the confusion - it's JBoss EAP 6.3.0.Alpha1 from the downloads area.  We have only recently managed to move off of JBoss 4.3 and are still ironing out a few kinks at the moment as we have a distinct lack of app server know how here. We were initially using JBoss7.1.2 but it kept stalling during startup, so following advice from the forums we moved up to the latest alpha - but have taken to referring to it by it's other tag in the startup log (7.4.0) for now as it avoids having to endlessly explain the 6 is 7 thing to others untill we get it all worked out.

               

               

              OK. Yes, it has been and continues to be an area of (unnecessary) confusion.

               

              JOC wrote:

               

              When I saw this problem happen, I was running from within eclipse using JBossTools (Version: 2.4.101.Final) I never start from cmd locally.

               

              In theory what you are seeing is plausible, more so because you are running the server within an IDE. The whole ManagementFactory.getPlatformMBeanServer() is tricky since as the javadoc http://docs.oracle.com/javase/7/docs/api/java/lang/management/ManagementFactory.html#getPlatformMBeanServer%28%29 states:

              Returns the platform MBeanServer. On the first call to this method, it first creates the platform MBeanServer by calling the MBeanServerFactory.createMBeanServer method and registers each platform MXBean in this platform MBeanServer with its ObjectName. This method, in subsequent calls, will simply return the initially created platform MBeanServer.

              ...

              If the system property javax.management.builder.initial is set, the platform MBeanServer creation will be done by the specified MBeanServerBuilder.

              So the first call to this method will trigger setting up the platform MBeanServer. The way this is integrated in JBoss AS7 and WildFly is that the JBoss Module bootstrap (for the server) will first look for a MBeanServerBuilder via ServiceLoader mechanism via the module's classloader and then set the javax.management.builder.initial system property to point it to that MBeanServerBuilder classname and call the ManagementFactory.getPlatformMBeanServer() so that it can initialize the platform MBean server. Here's the relevant code jboss-modules/src/main/java/org/jboss/modules/Main.java at master · jboss-modules/jboss-modules · GitHub. However, if before this happens, some other part of the code invokes that ManagementFactory.getPlatformMBeanServer() then it can end up initializing the default JRE's MBean server impl, in this case the com.sun.jmx.mbeanserver.JmxMBeanServer (which you are seeing) or even some other implementation if the other piece of code has setup the system property.


              I don't know if the IDE involves some piece of code which might be triggering this behaviour, but in theory it's possible. At this point though, I'm just guessing that this is what's happening based on the code I see. I don't have an explanation as to why you are seeing this behaviour only on few occasions. Any factors/patterns you can remember when this has happened, like maybe when you start it in debug mode via Eclipse?


              I can also see the reason why the JBoss AS/WildFly scripts don't explicitly set the javax.management.builder.initial system property to point to the one shipped in the server, since that MBeanServer impl is provided by the JMX subsystem which isn't guaranteed to be always present.


              I think you might want to bring this issue to the attention of the wildfly dev team by either (subscribing and) sending a mail to the wildfly-dev list wildfly-dev Info Page or maybe opening a WFLY JIRA WildFly - JBoss Issue Tracker. In either case, you can point them to this thread. Maybe someone there might know a better way of dealing with this.

              • 4. Re: getPlatformMBeanServer found wrong server
                Roland Bergler Newbie

                Same Problem here, using JBoss eap 6.3.1.

                Is there some work around for this problem?