Gartner article about JMX for Application Server Management

Discussions

News: Gartner article about JMX for Application Server Management

  1. Gartner estimates that 40 percent of unplanned downtime results from application failures, and concludes that the best way to reduce this problem is by building in application management functionality in the development process. For J2EE, JMX is available for this purpose. A brief Gartner article discusses this issue.

    Read Application Server Management: AD Implications. The article contains a small plug for Adventnet at the end, but the rest of the article is useful for justifying heavy use of JMX upfront in the development process.

    Christophe Ebro
    JMX Specification Lead

    Threaded Messages (28)

  2. The comments expressed in this article are right on. Application management is a must and best done thru a JMX implementation. While some app servers have some amount of JMX support, only the JBoss app server is built from the ground up with a JMX microkernel to allow full JMX management of all parts of the application. Two of the JBoss core developers are members of the Java Community Process (JCP) helping to guide the JMX specification. They also authored the first book on JMX, "JMX, Managing J2EE With Java Management Extensions"
  3. JMX seems to becoming more useful these days. I guess I better go and learn it. I'll start with the book by fluery and juha. Should be interesting. Has anybody read it?
  4. I've read that book. O'Reilly just recently published a book on JMX that I felt was better. It has been a while since I read the book from Fluery, but I remember that the book had a few errors and my impression was that it was too directed to JBoss, being the only major JMX user that I was aware of. The O'Reilly book is very well written and very easy to learn from. I highly recommend it.
  5. I've read both the Fleury/Lindfors book and the O'Reilly book. I think the Fleury/Lindfors book is much better. I would not say its directed at JBoss. Only the last few chapters do they use JBoss as an example. I would also recommed the "Jmx in Action" which is available free right here on this web site.
  6. Right, "JMX in Action" is definitely worth a read as it progressively introduces every main features of the JMX technology, wrapping things up with a nice overview of EJB and JMS management.

    Personnaly I do think JMX is a great step toward J2EE management, but it lacks some infrastructure which would provide the mere developer with an easy way to build / register any MBean for management purpose. Using XML files is a great way to build dynamic and/or model MBeans, but shouldn't this approach be part of the specifications ? Some other features are rather tough to use, such as the relation service. What about naming conventions for registerd MBeans ? I have heard of a coming JSR about "J2EE application management", but haven't had time to give a look at it.

    JBoss made a great step in providing everybody with a living example of a true running application based on a JMX bus. Their book reflects their expertise.

    I think JMX is an example of a very powerful technology, but lacks some good examples and infrastructure for anybody to really use it in an efficient manner.

    Laurent
  7. An intesting study of three large-scale services can be found at:

      http://citeseer.nj.nec.com/oppenheimer02architecture.html

    (There are links to the full version in the upper right hand corner).

    Here is a summary of there findings:
    "Despite the use of redundancy at many levels of the systems we studied, all the services experienced failures. The majority of these failures arose from networking problems and operator error. Networking problems stemmed from hardware and software (firmware) equipment failure
    that was compounded when the network was not engineered for redundancy through all possible paths among collocation centers, customers, and the network operations center. Operator error came up most frequently during system evolution, e.g., installing, configuring, and upgrading
    new hardware or software. Moreover, operator errors often remained latent and were then the root cause of subsequent failures whose immediate trigger was a hardware or software problem.

    Finally, we note that operator error is rarely prevented or ameliorated by existing techniques for system redundancy." - Oppenheimer & Patterson

    One point (my own) about JMX. While it looks like a great solution for adding managment hooks into our applications, it doesn't help to make nice user interfaces for the operations staff which is where I think a lot of human error will occur.


  8. <snip>
    One point (my own) about JMX. While it looks like a great solution for adding managment hooks into our applications, it doesn't help to make nice user interfaces for the operations staff which is where I think a lot of human error will occur.
    </snip>

    Your point is well taken. A great first stab at this problem is the open source solution, MC4J, a gui console for J2EE JMX based app servers.

    http://mc4j.sourceforge.net/


  9. Nice. Take a look at their WLS integration. The problem is that you'll need a bunch of classes from the server you are going to administer to load the MBeans plus all references. In the worst case you have to load all app server classes (it seems that's the case with WLS). As JMS, JMX is an interface spec, not a wire protocol. A wire protocol would be much easier (like with SNMP) to write admin consoles for.

    -- Andreas
  10. Having to have the client classes is a big drawback to JMX. I don't see why building WebService-like administration is not the way to go. JMX is really nothing more than JNDI.

    There's no there there, other than a nice buzzword for the resume.
  11. Can JMX be used to manage web services?
  12. Sartoris,

       What do you mean by "client classes" when you say that the big drawback to JMX is having to load client classes? JMX is hooking into app servers, so it only needs the bytecode for app server classes.
       Also, WebService-like management consoles are a horrible idea because sending SOAP documents over the wire will eat up too much of your bandwidth, thus resulting in your management console itself being one of the reasons why your app server is performing poorly!
       Thirdly, what do you mean that JMX is like JNDI? How is finding information on the instantiation and execution of MBeans anything like doing a naming/directory lookup, especially if the JMX packages reside on the same server instance as the beans themselves?

    Thanks,

    Basil.
  13. I could be totally wrong on the whole JMX idea. But my reading and running some examples lead me to see JMX as a means to expose objects running in some other process; mostly as a means to administer that other process.

    That means that if some client wants to communicate with the other process it needs to have those client classes and proxy classes to do so; just like RMI.

    If I want to allow the outside world to be able to administer me, an application, why not expose myself (;-)) or at least those parts that are administerable (using proper security, of course).

    "Also, WebService-like management consoles are a horrible idea because sending SOAP documents over the wire will eat up too much of your bandwidth, thus resulting in your management console itself being one of the reasons why your app server is performing poorly!"

    The overhead of marshalling fat objects has to be non-minimal, too. I would venture also that administration of an application is done infrequently.

    "Thirdly, what do you mean that JMX is like JNDI? "
    I guess I didn't go far enough. But registering an MBean
    is really just attaching an object instance to the JNDI tree, right? This could always be done...before JMX was hatched.

    I must be missing something about what is new and useful about JMX. If you know please tell me.
  14. <expose objects running in some other process>
    <like a web service>
    <like jndi>

    No. When you want to admin an MBean in some other process, you only need the RMI proxy class for the MBeanServer. All access to the MBean, regardless of whether the caller is in same JVM as MBean or not is done thru the MBeanServer. All access is done by telling the MBeanServer, the name of the MBean, the method name, an array of objects to pass for the method signature, and an array of Strings giving the class names of the objects in the method signature. The only marshalling that takes place is the marshalling of the objects in the method signature - no marshalling of the object being managed. The only similarity between MBeanServer and Jndi is that they both map names to objects. If anything, the functionaliy of Jndi is a subset of the functionality of JMX.
  15. As a client, if I pass foos as object to MBean methods or receive bars from MBean methods I need foo and bar classes. Which means I have to be version wary of foos and bars. In other words I have all the baggage of RMI.

    Why is this a good way to do things vis-a-vis web services?
    I'm truly looking for answers. Please help!
  16. We run WebSphere in our shop and we do have an interest in JMX. We would like to include JMX in our current development efforts if WebSphere is slated to support JMX at some point and if the JMX MBeans we develop today can be deployed "as is" later in WebSphere.

    Since JMX is not built into WebSphere (WAS, for short), we will be forced to use the JMX Reference Implementation (or invest in something like ManageEngine, which needs to be thrown away if/when WAS supports JMX) and run our MBeans in a separate JVM, outside of WAS. Since the resources such as the EJBs that we want to monitor themselves run inside WAS, the MBeans deployed in RI should only be wrappers to the actual resources on WAS and they should use RMI to communicate with the actual resources on WAS.

    We are wondering if this will buy as anything or if we should wait until WAS supports JMX.

    Thanks for your comments...

    -Srini Santhanam
    Application ARchitecture
    RBC Dain Rauscher
  17. <snip>
    We are wondering if this will buy as anything or if we should wait until WAS supports JMX.
    </snip>

    My advise is to give up altogether on WAS and build your app on JBoss. I had a contract that ended recently that lasted 2 years working with WAS and my biggest complaint about WAS was they are about 2 years behind the times in technology, using old JDKs, etc. When and if they ever do come out with JMX support, you can bet that it will be using an old version of JMX.

    JBoss, on the other hand, is ahead of the technology curve and supports a lot of the features in the next version of JMX.
  18. Greg-

    While I appreciate your thoughts regarding WebSphere and JBoss (by the way, you as an Authorized Consultant with JBoss, as I understand from a Yahoo search, have a vested interest in promoting JBoss, as is evident from your previous posts in this thread), it is not so easy for enterprises to throw away their multi-million dollar investments in an appserver. Also, there are multitude of reasons as to why WebSphere is very attractive for us.

    If you have a direct answer to my question, pl. feel free to answer. If not, just sit tight and leave it for others to respond...

    Thanks...
    -Srini
  19. Srinivasan,

    While your comments about my afiliation with JBoss are all true and my previous comments to you were somewhat tongue in cheek since I don't know the reasons that went into the decision to use WAS.

    If you want more of a direct answer. Lets try this. First, I don't see why you assume you would be forced to use the Sun RI to JMX. Why not use the JBoss JMX module, alone. Or there is another Open Source implementation of JMX on Sourceforge. The only thing I can think of that you would get by starting now on the JMX path, is the experience. Be aware, that the next major version of JMX will include EJBs being actual MBeans, not just wrapped by an MBean. If you wait for WAS, you will always be behind the curve.
  20. "Be aware, that the next major version of JMX will include EJBs being actual MBeans, not just wrapped by an MBean."

    Is this an implementation issue, or will EJB developers notice this change as well? Are the interfaces changing? I was very interested that you mentioned this.

    Steve

  21. "Is this an implementation issue, or will EJB developers notice this change as well? Are the interfaces changing? I was very interested that you mentioned this."

    http://jcp.org/jsr/detail/77.jsp
  22. I assume you're referring to the MEJB portion? I just downloaded the spec just now.
    Steve
  23. Greg,

    > http://jcp.org/jsr/detail/77.jsp

    What does JSR 77 have to do with

    > "Be aware, that the next major version of JMX
    > will include EJBs being actual MBeans, not just
    > wrapped by an MBean."

    ?

    --
    Cedric
  24. And what about WebSphere 5?
    Does this version support JMX?


    Thank you,
     Dmitry Namiot
     Coldbeans
  25. We would like to include JMX in our current development

    > efforts if WebSphere is slated to support JMX at some point

    If you look at the latest public draft of the J2EE 1.4 specification you will notice that JMX is included as part of the platform. So if WebSphere intents to target the 1.4 specification, they will have to include JMX.

    Also I would not recommed using the JMX reference implementation outside prototyping or learning to use MBeans. Because it is just that, a reference implementation. There are free JMX implementations available (for instance we provide a standalone JBossMX binary download). Also the IBM Tivoli team has been working on their JMX implementation for quite a while now which is also publicly available.

    HTH,

    --
    Juha Lindfors
    Author of "JMX: Managing J2EE with Java Management Extensions"
  26. In response to ManageEngine and forthcoming WAS support for JMX, there are a couple of important points to consider.

    First, WAS support for JMX will do little for managing your applications. Rather it will be focused on the application server, with no ability for you to control the JMX instrumentation of your applications.

    Second, ManageEngine works with any JMX implementation and generates JMX MBeans for your application instrumentation. This will not be throwaway, and can be re-used in any JMX implementation including JBoss. We will be making every effort to ensure it works with the latest WAS JMX.

    We'd welcome the opportunity to clarify any other concerns you have about using our tools.
    Tony Thomas
    AdventNet, Inc.
  27. As a client, if I pass foos as object to MBean methods or

    > receive bars from MBean methods I need foo and bar classes.
    > Which means I have to be version wary of foos and bars. In
    > other words I have all the baggage of RMI

    Have a look at Open MBeans, they might provide some answers for you in this case.

    On the other hand, it should not be that big of a task to build a basic WSDL adaptor for your MBean server.

    HTH,

    --
    Juha Lindfors
    Author of "JMX: Managing J2EE with Java Management Extensions"


  28. > Nice. Take a look at their WLS integration. The problem
    > is that you'll need a bunch of classes from the server
    > you are going to administer to load the MBeans plus all
    > references. In the worst case you have to load all app
    > server classes (it seems that's the case with WLS). As
    > JMS, JMX is an interface spec, not a wire protocol. A
    > wire protocol would be much easier (like with SNMP) to
    > write admin consoles for.

    Just for reference, and as others have talked about, server classes are not generally needed for JMX consoles unless they want to support specific complex type editing. Parts of the specification like OpenMBeans are designed to limit the types to a few specific types that can be supported by any console implementer.

    The reason that MC4J requires the WL classes has more to do with the way Bea implemented their custom JRMP implementation. A simple solution would be for Bea to release a client jar for making remote JRMP calls.

    Another option would be the use of IIOP to connect to weblogic servers, but there are some known issues with connecting to certain server side objects in WL, including the MBeanHome that provides remote MBeanServer access.
  29. Hi Techies,
     Just would like to know if any one has info. on what
    is resource/memory footprint of the JMX probes on the
    commonly used J2EE containers such as weblogic, websphere.

     Any Articles/pointers on the JMX overheads while it measures
    cluster information would be great.

    Thanks In Advance,
    Anand