6 Replies Latest reply on Jun 17, 2010 3:47 PM by David Lloyd

    JMX and domain management

    Brian Stansberry Master

      Some thoughts on how JMX intersects with domain management.

       

      1. The primary goal of AS 7 is to develop a management API that has clearly delimited boundaries, can be fully supported and is stable across releases. JMX is not very good fit for this because:
        1. The type system of the domain model may not map very well to what JMX supports.
        2. Projects we integrate often support usage outside of JBoss AS and have developed JMX-based management interfaces appropriate for such use. Simply by getting hold of the MBeanServer in the AS, those projects can expose those interfaces, and my assumption is they will do so. However, this is counter to the desire for a stable API with clearly delimited boundaries. IMO it is not realistic to expect that every project we integrate will conform it's JMX interface to the AS' requirements
        3. Even if projects did conform to AS' requirements,  the services and their JMX interfaces are deployed on Servers, not on the DomainController. The AS 7 management architecture is based on using the DC as the central point for performing management operations. (We may have exceptions to that, but those will be well-defined exceptions.)
      2. For the above reasons, the primary management interfaces for AS 7 should be our programatic interface and a REST interface.
      3. All that said, people like to use JMX for management! So, to the extent we can, IMO we should expose a JMX management interface.

       

      Proceeding from the above:

       

      1. The DC should expose a JMX interface.
      2. Said interface does not need to express the entire management API. It can be limited to that portion of the overall API that can properly be expressed in JMX.
      3. The portion of the management API that is exposed via JMX should have a separate JMX domain namespace from any other JMX interface exposed by any project. For now I'll call this the jboss.as.mgmt domain.
      4. The documentation should clearly state that the only portion of the JMX interface exposed by an AS 7 domain member that should be considered a stable API is that portion in the jboss.as.mgmt domain.
      5. The documentation should clearly state that using any JMX interface outside the jboss.as.mgmt domain is at your own risk, and in particular that setting attributes and invoking operations could lead to the configuration of the relevant Server being inconsistent with the domain.
      6. When AS 7 is productized, use of any JMX interface outside the jboss.as.mgmt domain should be unsupported.

       

      We can look into whether there should be a jboss.as.mgmt JMX interface on individual servers, i.e. beyond the DC. Well, at least whether there should be a writable interface.

       

      Above statements about "use at your own risk" aside, the JMX interfaces different projects expose will likely include things not available via the official domain management API. (New features, obscure settings, etc.)

        • 1. Re: JMX and domain management
          David Lloyd Master

          I think most of this is also true if you're talking about JMX as it relates to Server Manager instances and the host config.

           

          Also it's worth noting that monitoring/metrics kinds of things are probably safe to expose/query via JMX; sometimes it's nice to just hook up jconsole and have a nice graph of mem usage or whatever.

          • 2. Re: JMX and domain management
            Emanuel Muckenhuber Master

            Yeah, i think we can most likely expose a subset of the most common management operation through JMX.

             

            I assume that the REST interface is going to expose both, configuration and metrics. How about the programmatic interface. So far we mostly talked about the actual domain model used for configuration. Whereas i don't see that runtime metrics fit in a configuration API and should be separate.

             

            Do we know what the console team wants to use a management API? The REST or programmatic approach?

            • 3. Re: JMX and domain management
              mazz Master

              Emanuel Muckenhuber wrote:

               

              Do we know what the console team wants to use a management API? The REST or programmatic approach?

               

              Don't take this as an absolute, but rather just my opinion - I think we'd prefer a programmatic approach (by that I assume you mean we consume some client jar of yours and use its Java API to connect, make management calls, then disconnect from your management interface). I say this since it would provide a more strongly typed interface. REST as I understand it provides more along the lines of an HTTP request/response type of interface, thus more loosely coupled.

              • 4. Re: JMX and domain management
                Emanuel Muckenhuber Master

                John Mazzitelli wrote:

                Don't take this as an absolute, but rather just my opinion - I think we'd prefer a programmatic approach (by that I assume you mean we consume some client jar of yours and use its Java API to connect, make management calls, then disconnect from your management interface). I say this since it would provide a more strongly typed interface. REST as I understand it provides more along the lines of an HTTP request/response type of interface, thus more loosely coupled.

                Hmm, ok. What do you mean by strongly typed interface exactly - a complete POJO model containing all configuration, metrics and managed operations? I'm asking since looking at rhq-plugins.xml and the way e.g. the current jboss-man/ProfileService integration is done does not seem to fit in particular. Would that mean a POJO model requires hard coded rhq plugins and is that what you have in mind?

                AFAIK using the metadata/deployment descriptors directly was the original plan (before jboss-man), but can't remember what the problems were and why it did not happen.

                • 5. Re: JMX and domain management
                  Dimitris Andreadis Master

                  How are you planing to map the "Domain Model" to JMX? Arbitrarily by hand, meaning that the JMX interface is maintained in tandem with the domain model. I suppose we don't have a "formal" language for describing the domain model so that the JMX representation could be generated dynamically, right?

                   

                  Also keep in mind that at some point we might be asked to implement a jsr77 view, if it's not deprecated.

                  • 6. Re: JMX and domain management
                    David Lloyd Master

                    Dimitris Andreadis wrote:

                     

                    How are you planing to map the "Domain Model" to JMX? Arbitrarily by hand, meaning that the JMX interface is maintained in tandem with the domain model. I suppose we don't have a "formal" language for describing the domain model so that the JMX representation could be generated dynamically, right?

                    Depends - does anyone have any ideas as far as requirements for the domain JMX area that Brian postulated?