JMX for Grid-Based Applications

Discussions

News: JMX for Grid-Based Applications

  1. JMX for Grid-Based Applications (9 messages)

    This post talks about a (fairly) simple technique that solves the problem of how you get a unified view of JMX Management Beans in a distributed application. This is proving useful in a number of application projects we are doing where the application MBeans, for example worker beans are distributed around the network when deployed in the GigaSpaces Service Grid. The technique describes how a new protocol can be added to enable JMX agents and JMX servers to find each other in a network deployment. The protocol uses the GigaSpace as the rendezvous point, but the approach can be easily adapted to work with other network registration and rendezvous technologies. A Brief History of JMX JMX has been around for a long time as one of the core APIs in J2EE and recent versions of Java have seen it incorporated into the JVM to provide memory and other basic stats. The basics of JMX are pretty simple: you instrument your applications by providing one or more management beans MBeans. MBeans provide read-only and read-write attributes, and operations that provide information and enable the application's management characteristics to be controlled. MBeans are published to the world by registering them with an MBeanServer. MBeans are interacted with by a separate agent, which finds MBeans in the MBeanServer and provides a UI to interact with them. Often this UI takes the form of a generic user interface based on properties provided by the MBean, or as specific to the application as required. The original JMX specs were charmingly vague about where you might find an MBeanServer to register with or how you'd connect to one from the agent side. In more recent times, the JVM provides a default MBeanServer inside the JVM. As well as providing management capability for the JVM this MBeanServer can act as a repository for application MBeans. The jconsole provided with Java 1.6 provides a decent, if primitive, GUI for you to see the MBeans registered with the JVM's MBeanServer and interact with them. JMX JSR-160 Connectors JMX also now provides connectors that facilitate remote connection between agent and server, and come in two flavours: server-side and client-side. The server-side connector enables you to set up a connection channel to talk to the MBeanServer remotely, for example by exporting an RMI stub. The client-side connector provides the means of binding to the server-side connector and establishing a connection, for example via JNDI lookup of the server-side connector's RMI stub. If you use Spring, you can simply declare connectors in Spring configuration, as follows: The client-side connector is declared as: JMX Issues Specific to the Grid To read the rest, go to http://stevecolwill.blogspot.com/2008/11/jmx-for-grid-based-applications_03.html .

    Threaded Messages (9)

  2. Re: JMX for Grid-Based Applications[ Go to top ]

    While it's always more fun to build it yourself, Coherence already provides a view of an entire distributed system from any point in the system: http://coherence.oracle.com/display/COH34UG/How+to+Manage+Coherence+Using+JMX ;-) Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, C++ and .NET
  3. Re: JMX for Grid-Based Applications[ Go to top ]

    Our new product release being made available this week has support for publishing our probes multi-resource metering and costing data to the local MBeanServer along with a probes extension provider that also publishes this same data to the Coherence registry giving you a grid (cluster) wide via from a single JMX console. Note: I would not recommend using jconsole as it has terrible performance in renderer anything more than a hundred MBeans - we can register thousands of metering metrics and all activity based. William
  4. Re: JMX for Grid-Based Applications[ Go to top ]

    We rolled our own solution, with our own failover and autodiscovery mechanism as extra, using Cluster4Spring and Terracotta. We'll show our solution on Devoxx: http://www.devoxx.com/display/JV08/Dynamic+service+management+in+high+resolution+monitoring+systems * Service auto-discovery & failover with Cluster4spring and JMX * Service state replication with Terracotta * Dynamic service management through a JMX proxy layer
  5. Re: JMX for Grid-Based Applications[ Go to top ]

    Cameron The link you mention seems to point at Coeherence JMX management pages. To be clear, my original piece is aimed at managing *application* artifacts deployed to the grid, rather than managing the grid infrastructure itself. The scheme outlined can be adapted to use any suitable network repository technology including Coherence, or Terracotta. cheers Steve
  6. Re: JMX for Grid-Based Applications[ Go to top ]

    Steve, The Coherence JMX management framework will make any MBean (Grid related or not) visible in any other node on the grid. Which means you can connect a management console to one node and see all MBeans registered locally with MBeanServers in each JVM (node). This integration is incredibly simple even in version 3.3. We publish thousands of resource metering measurements this way with a few lines of integration code and one Coherence API call. Measurements do not have to be any way related to the grid. William
  7. Re: JMX for Grid-Based Applications[ Go to top ]

    Evident Software released a new product called ClearStone Live. It provides real-time monitoring for Coherence 3.3 and 3.4. The product leverages the Coherence JMX management framework. We collection thousands of measurements and attributes across the entire data grid thru a single customized out-of-the-box mbeanserver. Our visualizations and analytics allows users to look at 24-hours of continuous real-time data grid performance and activity. For more information, check out the following URL: http://www.evidentsoftware.com/products/clearstone_live.aspx
  8. Re: JMX for Grid-Based Applications[ Go to top ]

    Just to be clear JXInsight can make available thousands of metering measurements per node and these measurements are *** not *** related to the grid itself but to the software execution above, below and within the grid runtime. Also we are activity based which is not the case for any of the measurements published by Evident or Coherence because they are focused on the behavior of the cache at the system level (traditional costing approach) and have no insight into who (groups/cost centers) is actually using the grid and why (tracking). This is remarkable different than Evident. William
  9. Re: JMX for Grid-Based Applications[ Go to top ]

    By the way another product similar to Evident in reporting solely system level Coherence grid-wide metrics but without the Startrek UI (black dashboard background) is RTView from SL (http://www.sl.com/). William
  10. Re: JMX for Grid-Based Applications[ Go to top ]

    The link you mention seems to point at Coeherence JMX management pages. To be clear, my original piece is aimed at managing *application* artifacts deployed to the grid, rather than managing the grid infrastructure itself.
    As the other responses indicated, the MBeans of the application artifacts (or any MBean, e.g. the Java platform MBeans) are automatically clustered once they are registered with Coherence. We also added some extra bits to support this efficiently in grid architectures. For example, when grids get much larger than a few servers, we found that the access patterns for the remote MBeans could cause major network utilization if we didn't add some significant optimizations. Among other options, we added refresh-expired, refresh-ahead and refresh-behind support; you can read about those on the link I posted previously. If you get a chance, check this one out: http://coherence.oracle.com/display/COH34UG/Configuring+Custom+MBeans That's probably a better link for the topic of custom MBeans than the one that I posted originally. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, .NET and C++