Java Management Extensions(JMX)

Overview of the JMX Technology

The Java Management Extensions (JMX) technology is a standard part of the Java Platform, Standard Edition (Java SE platform). The JMX technology was added to the platform in the Java 2 Platform, Standard Edition (J2SE) 5.0 release.
The JMX technology provides a simple, standard way of managing resources such as applications, devices, and services. Because the JMX technology is dynamic, you can use it to monitor and manage resources as they are created, installed and implemented. You can also use the JMX technology to monitor and manage the Java Virtual Machine (Java VM).
The JMX specification defines the architecture, design patterns, APIs, and services in the Java programming language for management and monitoring of applications and networks.
Using the JMX technology, a given resource is instrumented by one or more Java objects known as Managed Beans, or MBeans. These MBeans are registered in a core-managed object server, known as an MBean server. The MBean server acts as a management agent and can run on most devices that have been enabled for the Java programming language.
The specifications define JMX agents that you use to manage any resources that have been correctly configured for management. A JMX agent consists of an MBean server, in which MBeans are registered, and a set of services for handling the MBeans. In this way, JMX agents directly control resources and make them available to remote management applications.
The way in which resources are instrumented is completely independent from the management infrastructure. Resources can therefore be rendered manageable regardless of how their management applications are implemented.
The JMX technology defines standard connectors (known as JMX connectors) that enable you to access JMX agents from remote management applications. JMX connectors using different protocols provide the same management interface. Consequently, a management application can manage resources transparently, regardless of the communication protocol used. JMX agents can also be used by systems or applications that are not compliant with the JMX specification, as long as those systems or applications support JMX agents.

Why Use the JMX Technology?

The JMX technology provides developers with a flexible means to instrument Java technology-based applications (Java applications), create smart agents, implement distributed management middleware and managers, and smoothly integrate these solutions into existing management and monitoring systems.

• The JMX technology enables Java applications to be managed without heavy investment.
  A JMX technology-based agent (JMX agent) can run on most Java technology-enabled devices. Consequently, Java applications can become manageable with little impact on their design. A Java application needs only to embed a managed object server and make some of its functionality available as one or several managed beans (MBeans) registered in the object server. That is all it takes to benefit from the management infrastructure.
• The JMX technology provides a standard way to manage Java applications, systems, and networks.
  For example, the Java Platform, Enterprise Edition (Java EE) 5 Application Server conforms to the JMX architecture and consequently can be managed by using JMX technology.
• The JMX technology can be used for out-of-the-box management of the Java VM.
  The Java Virtual Machine (Java VM) is highly instrumented using the JMX technology. You can start a JMX agent to access the built-in Java VM instrumentation, and thereby monitor and manage a Java VM remotely.
• The JMX technology provides a scalable, dynamic management architecture.
  Every JMX agent service is an independent module that can be plugged into the management agent, depending on the requirements. This component-based approach means that JMX solutions can scale from small-footprint devices to large telecommunications switches and beyond. The JMX specification provides a set of core agent services. Additional services can be developed and dynamically loaded, unloaded, or updated in the management infrastructure.
• The JMX technology leverages existing standard Java technologies.
  Whenever needed, the JMX specification references existing Java specifications, for example, the Java Naming and Directory Interface (J.N.D.I.) API.
• The JMX technology-based applications (JMX applications) can be created from a NetBeans IDE module.
  You can obtain a module from the NetBeans Update Center (select Tools -> Update Center in the NetBeans interface) that enables you to create JMX applications by using the NetBeans IDE. This reduces the cost of development of JMX applications.
• The JMX technology integrates with existing management solutions and emerging technologies.
  The JMX APIs are open interfaces that any management system vendor can implement. JMX solutions can use lookup and discovery services and protocols such as Jini network technology and the Service Location Protocol (SLP).

Architecture of the JMX Technology

The JMX technology can be divided into three levels, as follows:

• Instrumentation
• JMX agent
• Remote management

Instrumentation

To manage resources using the JMX technology, you must first instrument the resources in the Java programming language. You use Java objects known as MBeans to implement the access to the resources' instrumentation. MBeans must follow the design patterns and interfaces defined in the JMX specification. Doing so ensures that all MBeans provide managed resource instrumentation in a standardized way. In addition to standard MBeans, the JMX specification also defines a special type of MBean called an MXBean. An MXBean is an MBean that references only a pre-defined set of data types. Other types of MBean exist, but this trail will concentrate on standard MBeans and MXBeans.
Once a resource has been instrumented by MBeans, it can be managed through a JMX agent. MBeans do not require knowledge of the JMX agent with which they will operate.
MBeans are designed to be flexible, simple, and easy to implement. Developers of applications, systems, and networks can make their products manageable in a standard way without having to understand or invest in complex management systems. Existing resources can be made manageable with minimum effort.
In addition, the instrumentation level of the JMX specification provides a notification mechanism. This mechanism enables MBeans to generate and propagate notification events to components of the other levels.

JMX Agent

A JMX technology-based agent (JMX agent) is a standard management agent that directly controls resources and makes them available to remote management applications. JMX agents are usually located on the same machine as the resources they control, but this arrangement is not a requirement.
The core component of a JMX agent is the MBean server, a managed object server in which MBeans are registered. A JMX agent also includes a set of services to manage MBeans, and at least one communications adaptor or connector to allow access by a management application.
When you implement a JMX agent, you do not need to know the semantics or functions of the resources that it will manage. In fact, a JMX agent does not even need to know which resources it will serve because any resource instrumented in compliance with the JMX specification can use any JMX agent that offers the services that the resource requires. Similarly, the JMX agent does not need to know the functions of the management applications that will access it.

Remote Management

JMX technology instrumentation can be accessed in many different ways, either through existing management protocols such as the Simple Network Management Protocol (SNMP) or through proprietary protocols. The MBean server relies on protocol adaptors and connectors to make a JMX agent accessible from management applications outside the agent's Java Virtual Machine (Java VM).
Each adaptor provides a view through a specific protocol of all MBeans that are registered in the MBean server. For example, an HTML adaptor could display an MBean in a browser.
Connectors provide a manager-side interface that handles the communication between manager and JMX agent. Each connector provides the same remote management interface through a different protocol. When a remote management application uses this interface, it can connect to a JMX agent transparently through the network, regardless of the protocol. The JMX technology provides a standard solution for exporting JMX technology instrumentation to remote applications based on Java Remote Method Invocation (Java RMI).

Monitoring and Management of the Java Virtual Machine

The JMX technology can also be used to monitor and manage the Java virtual machine (Java VM).
The Java VM has built-in instrumentation that enables you to monitor and manage it by using the JMX technology. These built-in management utilities are often referred to as out-of-the-box management tools for the Java VM. To monitor and manage different aspects of the Java VM, the Java VM includes a platform MBean server and special MXBeans for use by management applications that conform to the JMX specification.

Platform MXBeans and the Platform MBean Server

The platform MXBeans are a set of MXBeans that is provided with the Java SE platform for monitoring and managing the Java VM and other components of the Java Runtime Environment (JRE). Each platform MXBean encapsulates a part of Java VM functionality, such as the class-loading system, just-in-time (JIT) compilation system, garbage collector, and so on. These MXBeans can be displayed and interacted with by using a monitoring and management tool that complies with the JMX specification, to enable you to monitor and manage these different VM functionalities. One such monitoring and management tool is the Java SE platform's JConsole graphical user interface (GUI).
The Java SE platform provides a standard platform MBean server in which these platform MXBeans are registered. The platform MBean server can also register any other MBeans you wish to create.

JConsole

The Java SE platform includes the JConsole monitoring and management tool, which complies with the JMX specification. JConsole uses the extensive instrumentation of the Java VM (the platform MXBeans) to provide information about the performance and resource consumption of applications that are running on the Java platform.

Out-of-the-Box Management in Action

Because standard monitoring and management utilities that implement the JMX technology are built into the Java SE platform, you can see the out-of-the-box JMX technology in action without having to write a single line of JMX API code. You can do so by launching a Java application and then monitoring it by using JConsole.

Monitoring an Application by Using JConsole

This procedure shows how to monitor the Notepad Java application. Under releases of the Java SE platform prior to version 6, applications that you want to monitor with JConsole need to be started with the following option.

-Dcom.sun.management.jmxremote

However, the version of JConsole provided with the Java SE 6 platform can attach to any local application that supports the Attach API. In other words, any application that is started in the Java SE 6 HotSpot VM is detected automatically by JConsole, and does not need to be started using the above command-line option.

1. Start the Notepad Java application, by using the following command in a terminal window:

   java -jar jdk_home/demo/jfc/Notepad/Notepad.jar
   

   Where jdk_home is the directory in which the Java Development Kit (JDK) is installed. If you are not running version 6 of the Java SE platform, you will need to use the following command:

java -Dcom.sun.management.jmxremote -jar jdk_home/demo/jfc/Notepad/Notepad.jar

2. Once Notepad has opened, in a different terminal window, start JConsole by using the following command:

   jconsole
   

   A New Connection dialog box is displayed.
3. In the New Connection dialog box, select Notepad.jar from the Local Process list, and click the Connect button.JConsole opens and connects itself to the Notepad.jar process. When JConsole opens, you are presented with an overview of monitoring and management information related to Notepad. For example, you can view the amount of heap memory the application is consuming, the number of threads the application is currently running, and how much central procesing unit (CPU) capacity the application is consuming.
4. Click the different JConsole tabs.Each tab presents more detailed information about the different areas of functionality of the Java VM in which Notepad is running. All the information presented is obtained from the various JMX technology MXBeans mentioned in this trail. All the platform MXBeans can be displayed in the MBeans tab. The MBeans tab is examined in the next section of this trail.
5. To close JConsole, select Connection -> Exit.

    MBeans

This lesson introduces the fundamental concept of the JMX API, namely managed beans, or MBeans.
An MBean is a managed Java object, similar to a JavaBeans component, that follows the design patterns set forth in the JMX specification. An MBean can represent a device, an application, or any resource that needs to be managed. MBeans expose a management interface that consists of the following:

• A set of readable or writable attributes, or both.
• A set of invokable operations.
• A self-description.

The management interface does not change throughout the life of an MBean instance. MBeans can also emit notifications when certain predefined events occur.
The JMX specification defines five types of MBean:

• Standard MBeans
• Dynamic MBeans
• Open MBeans
• Model MBeans
• MXBeans

The examples in this trail demonstrate only the simplest types of MBean, namely standard MBeans and MXBeans.

Standard MBeans

This section presents an example of a straightforward, standard MBean.
A standard MBean is defined by writing a Java interface called SomethingMBean and a Java class called Somethingthat implements that interface. Every method in the interface defines either an attribute or an operation in the MBean. By default, every method defines an operation. Attributes and operations are methods that follow certain design patterns. A standard MBean is composed of an MBean interface and a class. The MBean interface lists the methods for all exposed attributes and operations. The class implements this interface and provides the functionality of the instrumented resource.
The following sections examine an example of a standard MBean and a simple JMX technology-enabled agent (JMX agent) that manages the MBean.

MBean Interface

An example of a basic MBean interface, HelloMBean, follows:

package com.example; 
 
public interface HelloMBean { 
 
    public void sayHello(); 
    public int add(int x, int y); 
 
    public String getName(); 
 
    public int getCacheSize(); 
    public void setCacheSize(int size); 
} 

By convention, an MBean interface takes the name of the Java class that implements it, with the suffix MBean added. In this case, the interface is called HelloMBean. The Hello class that implements this interface is described in the next section.
According to the JMX specification, an MBean interface consists of named and typed attributes that are readable and possibly writable, in addition to the named and typed operations that can be invoked by the applications that are managed by the MBean. The HelloMBean interface declares two operations: the Java methods add() andsayHello().
HelloMBean declares two attributes: Name is a read-only string, and CacheSize is an integer that can be both read and written. Getter and setter methods are declared to allow the managed application to access and possibly change the attribute values. As defined by the JMX specification, a getter is any public method that does not return void and whose name begins with get. A getter enables a manager to read the value of the attribute, whose type is that of the returned object. A setter is any public method that takes a single parameter and whose name begins with set. A setter enables a manager to write a new value in the attribute, whose type is the same as that of the parameter.
The implementation of these operations and attributes is shown in the following section.

MBean Implementation

The Hello Java class that follows implements the HelloMBean MBean interface:

package com.example; 
 
public class Hello [...] implements HelloMBean { 
    public void sayHello() { 
 System.out.println("hello, world"); 
    } 
 
    public int add(int x, int y) { 
 return x + y; 
    } 
 
    public String getName() { 
 return this.name; 
    } 
 
 
    public int getCacheSize() { 
 return this.cacheSize; 
    } 
 
    public synchronized void setCacheSize(int size) {
 [...]
 this.cacheSize = size; 
 
 System.out.println("Cache size now " + this.cacheSize); 
    } 
    
    [...]
 
    private final String name = "Reginald"; 
    private int cacheSize = DEFAULT_CACHE_SIZE; 
    private static final int DEFAULT_CACHE_SIZE = 200; 
}

The straightforward Hello class provides the definitions of the operations and attributes that are declared byHelloMBean. The sayHello() and add() operations are extremely simple, but real-life operations can be as simple or as sophisticated as needed.
The methods to get the Name attribute and to get and set the CacheSize attribute are also defined. In this example, theName attribute value never changes. However, in a real scenario this attribute might change as the managed resource runs. For example, the attribute might represent statistics such as uptime or memory usage. Here, the attribute is merely the name Reginald.
Calling the setCacheSize method enables you to alter the CacheSize attribute from its declared default value of 200. In a real scenario, changing the CacheSize attribute could require other operations to be performed, such as discarding entries or allocating new entries. This example merely prints a message to confirm that the cache size has changed. However, more sophisticated operations could be defined instead of the simple call to println().
With the Hello MBean and its interface thus defined, they can now be used to manage the resource they represent, as shown in the following section.

Creating a JMX Agent to Manage a Resource

Once a resource has been instrumented by MBeans, the management of that resource is performed by a JMX agent.
The core component of a JMX agent is the MBean server. An MBean server is a managed object server in which MBeans are registered. A JMX agent also includes a set of services to manage MBeans. See the API documentation for the MBeanServer interface for details of the MBean server implementation.
The Main class that follows represents a basic JMX agent:

package com.example; 
 
import java.lang.management.*; 
import javax.management.*; 
 
public class Main { 
 
   public static void main(String[] args) throws Exception { 
 
      MBeanServer mbs = ManagementFactory.getPlatformMBeanServer(); 
      ObjectName name = new ObjectName("com.example:type=Hello"); 
      Hello mbean = new Hello(); 
      mbs.registerMBean(mbean, name); 
      
      [...]
 
      System.out.println("Waiting forever..."); 
      Thread.sleep(Long.MAX_VALUE); 
   } 
} 

The JMX agent Main begins by obtaining an MBean server that has been created and initialized by the platform, by calling the getPlatformMBeanServer() method of the java.lang.management.ManagementFactory class. If no MBean server has been created by the platform already, then getPlatformMBeanServer() creates an MBean server automatically by calling the JMX method MBeanServerFactory.createMBeanServer(). The MBeanServerinstance obtained by Main is named mbs.
Next, Main defines an object name for the MBean instance that it will create. Every JMX MBean must have an object name. The object name is an instance of the JMX classObjectName and must conform to the syntax defined by the JMX specification. Namely, the object name must contain a domain and a list of key-properties. In the object name defined by Main, the domain is com.example (the package in which the example MBean is contained). In addition, the key-property declares that this object is of the type Hello.
An instance of a Hello object, named mbean, is created. The Hello object named mbean is then registered as an MBean in the MBean server mbs with the object name name, by passing the object and the object name into a call to the JMX method MBeanServer.registerMBean().
With the Hello MBean registered in the MBean server, Main simply waits for management operations to be performed on Hello. In this example, these management operations are invoking sayHello() and add(), and getting and setting the attribute values.

Running the Standard MBean Example

Having examined the example classes, you can now run the example. In this example, JConsole is used to interact with the MBean.
To run the example, follow these steps:

1. Save the bundle of JMX API sample classes, jmx_examples.zip, to your working directory, work_dir.
2. Unzip the bundle of sample classes by using the following command in a terminal window.

unzip jmx_examples.zip

3. Compile the example Java classes from within the work_dir directory.

javac com/example/*.java

4. If you are running the Java Development Kit (JDK) version 6, start the Mainapplication with the following command.

   java com.example.Main
   

   If you are running a JDK version that is older than version 6, you will need to start the Main application with the following option specified, to expose the application for monitoring and management.
   

   java -Dcom.sun.management.jmxremote example.Main
   

   A confirmation that Main is waiting for something to happen is displayed.
5. Start JConsole in a different terminal window on the same machine.

   jconsole
   

   The New Connection dialog box is displayed, presenting a list of running JMX agents that you can connect to.
6. In the New Connection dialog box, select com.example.Main from the list and click Connect.A summary of your platform's current activity is displayed.
7. Click the MBeans tab.This panel shows all the MBeans that are currently registered in the MBean server.
8. In the left frame, expand the com.example node in the MBean tree.You see the example MBean Hello that was created and registered by Main. If you click Hello, you see its associated Attributes and Operations nodes in the MBean tree.
9. Expand the Attributes node of the Hello MBean in the MBean tree.The MBean attributes that were defined by the Hello class are displayed.
10. Change the value of the CacheSize attribute to 150.In the terminal window in which you started Main, a confirmation of this attribute change is generated.
11. Expand the Operations node of the Hello MBean in the MBean tree.The two operations declared by the Hello MBean, sayHello() and add(), are visible.
12. Invoke the sayHello() operation by clicking the sayHello button.A JConsole dialog box informs you that the method was invoked successfully. The message "hello, world" is generated in the terminal window in which Main is running.
13. Provide two integers for the add() operation to add and click the add button.The answer is displayed in a JConsole dialog box.
14. To close JConsole, select Connection -> Exit.

MXBeans

This section explains a special type of MBean, called MXBeans.
An MXBean is a type of MBean that references only a predefined set of data types. In this way, you can be sure that your MBean will be usable by any client, including remote clients, without any requirement that the client have access to model-specific classes representing the types of your MBeans. MXBeans provide a convenient way to bundle related values together, without requiring clients to be specially configured to handle the bundles.
In the same way as for standard MBeans, an MXBean is defined by writing a Java interface called SomethingMXBeanand a Java class that implements that interface. However, unlike standard MBeans, MXBeans do not require the Java class to be called Something. Every method in the interface defines either an attribute or an operation in the MXBean. The annotation @MXBean can be also used to annotate the Java interface, instead of requiring the interface's name to be followed by the MXBean suffix.
MXBeans existed in the Java 2 Platform, Standard Edition (J2SE) 5.0 software, in the packagejava.lang.management. However, users can now define their own MXBeans, in addition to the standard set that is defined in java.lang.management.
The main idea behind MXBeans is that types such as java.lang.management.MemoryUsage that are referenced in the MXBean interface, java.lang.management.MemoryMXBean in this case, are mapped into a standard set of types, the so-called Open Types that are defined in the package javax.management.openmbean. The exact mapping rules appear in the MXBean specification. However, the general principle is for simple types such as int or String to remain unchanged, while complex types such as MemoryUsage get mapped to the standard typeCompositeDataSupport.
The MXBean example consists of the following files, which are found in jmx_examples.zip:

• QueueSamplerMXBean interface
• QueueSampler class that implements the MXBean interface
• QueueSample Java type returned by the getQueueSample() method in the MXBean interface
• Main, the program that sets up and runs the example

The MXBean example uses these classes to perform the following actions:

• Defines a simple MXBean that manages a resource of type Queue<String>
• Declares a getter, getQueueSample, in the MXBean that takes a snapshot of the queue when invoked and returns a Java class QueueSample that bundles the following values together:
  • The time the snapshot was taken
  • The queue size
  • The head of the queue at that given time
• Registers the MXBean in an MBean server

MXBean Interface

The following code shows the example QueueSamplerMXBean MXBean interface:

package com.example; 
 
public interface QueueSamplerMXBean { 
    public QueueSample getQueueSample(); 
    public void clearQueue(); 
} 

Note that you declare an MXBean interface in exactly the same way as you declare a standard MBean interface. TheQueueSamplerMXBean interface declares a getter, getQueueSample and an operation, clearQueue.

Defining MXBean Operations

The MXBean operations are declared in the QueueSampler example class, as follows:

package com.example; 
 
import java.util.Date; 
import java.util.Queue; 
 
public class QueueSampler implements QueueSamplerMXBean { 
     
    private Queue queue; 
     
    public QueueSampler(Queue queue) { 
       this.queue = queue; 
    } 
     
    public QueueSample getQueueSample() { 
        synchronized (queue) { 
            return new QueueSample(new Date(), queue.size(), queue.peek()); 
        } 
    } 
     
    public void clearQueue() { 
        synchronized (queue) { 
            queue.clear(); 
        } 
    } 
} 

QueueSampler defines the getQueueSample() getter and clearQueue() operation that were declared by the MXBean interface. The getQueueSample() operation returns an instance of the QueueSample Java type which was created with the values returned by the java.util.Queue methods peek() and size(), and an instance ofjava.util.Date.

Defining the Java Type Returned by the MXBean Interface

The QueueSample instance returned by QueueSampler is defined in the QueueSample class, as follows:

package com.example; 
 
import java.beans.ConstructorProperties; 
import java.util.Date; 
 
public class QueueSample { 
     
    private final Date date; 
    private final int size; 
    private final String head; 
     
    @ConstructorProperties({"date", "size", "head"}) 
    public QueueSample(Date date, int size, String head) { 
        this.date = date; 
        this.size = size; 
        this.head = head; 
    } 
     
    public Date getDate() { 
        return date; 
    } 
     
    public int getSize() { 
        return size; 
    } 
     
    public String getHead() { 
        return head; 
    } 
}  
 
 

In the QueueSample class, the MXBean framework calls all the getters in QueueSample to convert the given instance into a CompositeData instance and uses the @ConstructorProperties annotation to reconstruct a QueueSampleinstance from a CompositeData instance.

Creating and Registering the MXBean in the MBean Server

So far, the following have been defined: an MXBean interface and the class that implements it, as well as the Java type that is returned. Next, the MXBean must be created and registered in an MBean server. These actions are performed by the same Main example JMX agent that was used in the standard MBean example, but the relevant code was not shown in the Standard MBean lesson.

package com.example; 
 
import java.lang.management.ManagementFactory; 
import java.util.Queue; 
import java.util.concurrent.ArrayBlockingQueue; 
import javax.management.MBeanServer; 
import javax.management.ObjectName; 
 
public class Main { 
 
    public static void main(String[] args) throws Exception { 
        MBeanServer mbs = ManagementFactory.getPlatformMBeanServer(); 
 
 [...]

        ObjectName mxbeanName = new ObjectName("com.example:type=QueueSampler");

        Queue queue = new ArrayBlockingQueue(10);
        queue.add("Request-1");
        queue.add("Request-2");
        queue.add("Request-3");
        QueueSampler mxbean = new QueueSampler(queue);

        mbs.registerMBean(mxbean, mxbeanName);
         
        System.out.println("Waiting..."); 
        Thread.sleep(Long.MAX_VALUE); 
    } 
} 
 

The Main class performs the following actions:

• Gets the platform MBean server.
• Creates an object name for the MXBean QueueSampler.
• Creates a Queue instance for the QueueSampler MXBean to process.
• Feeds the Queue instance to a newly created QueueSampler MXBean.
• Registers the MXBean in the MBean server in exactly the same way as a standard MBean.

Running the MXBean Example

The MXBean example uses classes from the jmx_examples.zip bundle that you used in the Standard MBeanssection. This example requires version 6 of the Java SE platform. To run the MXBeans example follow these steps:

1. If you have not done so already, save jmx_examples.zip into your work_dir directory.
2. Unzip the bundle of sample classes by using the following command in a terminal window.

unzip jmx_examples.zip

3. Compile the example Java classes from within the work_dir directory.

javac com/example/*.java

4. Start the Main application. A confirmation that Main is waiting for something to happen is generated.

java com.example.Main

5. Start JConsole in a different terminal window on the same machine. The New Connection dialog box is displayed, presenting a list of running JMX agents that you can connect to.

jconsole

6. In the New Connection dialog box, select com.example.Main from the list and click Connect.A summary of your platform's current activity is displayed.
7. Click the MBeans tab.This panel shows all the MBeans that are currently registered in the MBean server.
8. In the left frame, expand the com.example node in the MBean tree.You see the example MBean QueueSampler that was created and registered by Main. If you clickQueueSampler, you see its associated Attributes and Operations nodes in the MBean tree.
9. Expand the Attributes node.You see the QueueSample attribute appear in the right pane, with its value ofjavax.management.openmbean.CompositeDataSupport.
10. Double-click the CompositeDataSupport value.You see the QueueSample values date, head, and size because the MXBean framework has converted theQueueSample instance into CompositeData. If you had defined QueueSampler as a standard MBean rather than as an MXBean, JConsole would not have found the QueueSample class because it would not be in its class path. If QueueSampler had been a standard MBean, you would have received a ClassNotFoundExceptionmessage when retrieving the QueueSample attribute value. The fact that JConsole finds QueueSamplerdemonstrates the usefulness of using MXBeans when connecting to JMX agents through generic JMX clients such as JConsole.
11. Expand the Operations node.A button to invoke the clearQueue operation is displayed.
12. Click the clearQueue button.A confirmation that the method was invoked successfully is displayed.
13. Expand the Attributes node again, and double click on the CompositeDataSupport value.The head and size values have been reset.
14. To close JConsole, select Connection -> Exit