Chapter 3.  Qpid JMX Management Console

Table of Contents

3.1. Qpid JMX Management Console
3.1.1. Overview

3.1.  Qpid JMX Management Console

3.1.1.  Overview

The Qpid JMX Management Console is a standalone Eclipse RCP application that communicates with the broker using JMX.

3.1.1.1.  Configuring Management Users

The Qpid Java broker has a single source of users for the system. So a user can connect to the broker to send messages and via the JMX console to check the state of the broker.

Adding a new management user

The broker does have some minimal configuration available to limit which users can connect to the JMX console and what they can do when they are there.

There are two steps required to add a new user with rights for the JMX console.

  1. Create a new user login, see HowTo:???

  2. Grant the new user permission to the JMX Console

Granting JMX Console Permissions

By default new users do not have access to the JMX console. The access to the console is controlled via the file jmxremote.access.

This file contains a mapping from user to privilege.

There are three privileges available:

  1. readonly - The user is able to log in and view queues but not make any changes.

  2. readwrite - Grants user ability to read and write queue attributes such as alerting values.

  3. admin - Grants the user full access including ability to edit Users and JMX Permissions in addition to readwrite access.

This file is read at start up and can forcibly be reloaded by an admin user through the management console.

Access File Format

The file is a standard Java properties file and has the following format

<username>=<privilege>

If the username value is not a valid user (list in the specified PrincipalDatabase) then the broker will print a warning when it reads the file as that entry will have no meaning.

Only when the the username exists in both the access file and the PrincipalDatabase password file will the user be able to login via the JMX Console.

Example File

The file will be timestamped by the management console if edited through the console.

#Generated by JMX Console : Last edited by user:admin
#Tue Jun 12 16:46:39 BST 2007
admin=admin
guest=readonly
user=readwrite

3.1.1.2.  Configuring Qpid JMX Management Console

Configuring Qpid JMX Management Console

Qpid has a JMX management interface that exposes a number of components of the running broker. You can find out more about the features exposed by the JMX interfaces ???.

Installing the Qpid JMX Management Console
  1. Unzip the archive to a suitable location.

    SSL encrypted connections

    Recent versions of the broker can make use of SSL to encrypt their RMI based JMX connections. If a broker being connected to is making use of this ability then additional console configuration may be required, particularly when using self-signed certificates. See ??? for details.

JMXMP based connections

In previous releases of Qpid (M4 and below) the broker JMX connections could make use of the JMXMPConnector for additional security over its default RMI based JMX configuration. This is no longer the case, with SSL encrypted RMI being the favored approach going forward. However, if you wish to connect to an older broker using JMXMP the console will support this so long as the jmxremote_optional.jar file is provided to it. For details see ???.

Running the Qpid JMX Management Console

The console can be started in the following way, depending on platform:

  • Windows: by running the 'qpidmc.exe' executable file.

  • Linux: by running the 'qpidmc' executable.

  • Mac OS X: by launching the consoles application bundle (.app file).

Using the Qpid JMX Management Console

Please see Section 3.1.1.5, “ Qpid JMX Management Console User Guide ” for details on using this Eclipse RCP application.

Using JConsole

See ???

Using HermesJMS

HermesJMS also offers integration with the Qpid management interfaces. You can get instructions and more information from HermesJMS.

Using MC4J

MC4J is an alternative management tool. It provide a richer "dashboard" that can customise the raw MBeans.

Installation
  • First download and install MC4J for your platform. Version 1.2 beta 9 is the latest version that has been tested.

  • Copy the directory blaze/java/management/mc4j into the directory <MC4J-Installation>/dashboards

Configuration

You should create a connection the JVM to be managed. Using the Management->Create Server Connection menu option. The connection URL should be of the form: service:jmx:rmi:///jndi/rmi://localhost:8999/jmxrmi making the appropriate host and post changes.

Operation

You can view tabular summaries of the queues, exchanges and connections using the Global Dashboards->QPID tree view. To drill down on individual beans you can right click on the bean. This will show any available graphs too.

3.1.1.3.  Management Console Security

Management Console Security
SSL encrypted RMI (0.5 and above)

Current versions of the broker make use of SSL encryption to secure their RMI based JMX ConnectorServer for security purposes. This ships enabled by default, although the test SSL keystore used during development is not provided for security reasons (using this would provide no security as anyone could have access to it).

Broker Configuration

The broker configuration must be updated before the broker will start. This can be done either by disabling the SSL support, utilizing a purchased SSL certificate to create a keystore of your own, or generating a self-signed keystore.

The broker must be configured with a keystore containing the private and public keys associated with its SSL certificate. This is accomplished by setting the Java environment properties javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword respectively with the location and password of an appropriate SSL keystore. Entries for these properties exist in the brokers main configuration file alongside the other management settings (see below), although the command line options will still work and take precedence over the configuration file.

<management>
    <ssl>
        <enabled>true</enabled>
        <!-- Update below path to your keystore location, eg ${conf}/qpid.keystore  -->
        <keyStorePath>${conf}/qpid.keystore</keyStorePath>
        <keyStorePassword>password</keyStorePassword>
    </ssl>
</management>
JMX Management Console Configuration

If the broker makes use of an SSL certificate signed by a known signing CA (Certification Authority), the management console needs no extra configuration, and will make use of Java's built-in CA truststore for certificate verification (you may however have to update the system-wide default truststore if your CA is not already present in it).

If however you wish to use a self-signed SSL certificate, then the management console must be provided with an SSL truststore containing a record for the SSL certificate so that it is able to validate it when presented by the broker. This is performed by setting the javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword environment variables when starting the console. This can be done at the command line, or alternatively an example configuration has been made within the console's qpidmc.ini launcher configuration file that may pre-configured in advance for repeated usage. See the Section 3.1.1.5, “ Qpid JMX Management Console User Guide ” for more information on this configuration process.

JConsole Configuration

As with the JMX Management Console above, if the broker is using a self-signed SSL certificate then in order to connect remotely using JConsole, an appropriate trust store must be provided at startup. See ??? for further details on configuration.

Additional Information

More information on Java's handling of SSL certificate verification and customizing the keystores can be found in the http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#CustomizingStores.

JMXMP (M4 and previous)

In previous releases of Qpid (M4 and below) the broker, can make use of Sun's Java Management Extensions Messaging Protocol (JMXMP) to provide encryption of the JMX connection, offering increased security over the default unencrypted RMI based JMX connection.

Download and Install

This is possible by adding the jmxremote_optional.jar as provided by Sun. This jar is covered by the Sun Binary Code License and is not compatible with the Apache License which is why this component is not bundled with Qpid.

Download the JMX Remote API 1.0.1_04 Reference Implementation from ???. The included 'jmxremote-1_0_1-bin\lib\jmxremote_optional.jar' file must be added to the broker classpath:

First set your classpath to something like this:

CLASSPATH=jmxremote_optional.jar

Then, run qpid-server passing the following additional flag:

qpid-server -run:external-classpath=first

Following this the configuration option can be updated to enabled use of the JMXMP based JMXConnectorServer.

Broker Configuration

To enabled this security option change the security-enabled value in your broker configuration file.

    <management>
        <security-enabled>true</security-enabled>
    </management>

You may also (for M2 and earlier) need to set the following system properties using the environment variable QPID_OPTS:

QPID_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"

JMX Management Console Configuration

If you wish to connect to a broker configured to use JMXMP then the console also requires provision of the Optional sections of the JMX Remote API that are not included within the JavaSE platform.

In order to make it available to the console, place the 'jmxremote_optional.jar' (rename the file if any additional information is present in the file name) jar file within the 'plugins/jmxremote.sasl_1.0.1/' folder of the console release (on Mac OS X you will need to select 'Show package contents' from the context menu whilst selecting the management console bundle in order to reveal the inner file tree).

Following the the console will automatically load the JMX Remote Optional classes and attempt the JMXMP connection when connecting to a JMXMP enabled broker.

User Accounts & Access Rights

In order to access the management operations via JMX, users must have an account and have been assigned appropriate access rights. See ???

3.1.1.4.  Qpid JMX Management Console FAQ

Errors
How do I connect the management console to my broker using security ?

The ??? page will give you the instructions that you should use to set this up.

I am unable to connect Qpid JMX MC/JConsole to a remote broker running on Linux, but connecting to localhost on that machine works ?

The RMI based JMX ConnectorServer used by the broker requries two ports to operate. The console connects to an RMI Registry running on the primary (default 8999) port and retrieves the information actually needed to connect to the JMX Server. This information embeds the hostname of the remote machine, and if this is incorrect or unreachable by the connecting client the connection will fail.

This situation arises due to the hostname configuration on Linux and is generally encountered when the remote machine does not have a DNS hostname entry on the local network, causing the hostname command to return a loopback IP instead of a fully qualified domain name or IP address accessible by remote client machines. It is described in further detail at: ???

To remedy this issue you can set the java.rmi.server.hostname system property to control the hostname/ip reported to the RMI runtime when advertising the JMX ConnectorServer. This can also be used to dictate the address returned on a computer with multiple network interfaces to control reachability. To do so, add the value -Djava.rmi.server.hostname=<desired hostname/ip> to the QPID_OPTS environment variable before starting the qpid-server script.

3.1.1.5.  Qpid JMX Management Console User Guide

Qpid JMX Management Console User Guide

The Qpid JMX Management Console is a standalone Eclipse RCP application for managing and monitoring the Qpid Java server utilising its JMX management interfaces.

This guide will give an overview of configuring the console, the features supported by it, and how to make use of the console in managing the various JMX Management Beans (MBeans) offered by the Qpid Java server.

Startup & Configuration

Startup

The console can be started in the following way, depending on platform:

  • Windows: by running the qpidmc.exe executable file.

  • Linux: by running the qpidmc executable.

  • Mac OS X: by launching the Qpid Management Console.app application bundle.

SSL configuration

Newer Qpid Java servers can protect their JMX connections with SSL, and this is enabled by default. When attempting to connect to a server with this enabled, the console must be able to verify the SSL certificate presented to it by the server or the connection will fail.

If the server makes use of an SSL certificate signed by a known Signing CA (Certification Authority) then the console needs no extra configuration, and will make use of Java's default system-wide CA TrustStore for certificate verification (you may however have to update the system-wide default CA TrustStore if your certified is signed by a less common CA that is not already present in it).

If however the server is equipped with a self-signed SSL certificate, then the management console must be provided with an appropriate SSL TrustStore containing the public key for the SSL certificate, so that it is able to validate it when presented by the server. The server ships with a script to create an example self-signed SSL certificate, and store the relevant entries in a KeyStore and matching TrustStore. This script can serve as a guide on how to use the Java Keytool security utility to manipulate your own stores, and more information can be found in the JSSE Reference Guide: http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#CustomizingStores.

Supplying the necessary details to the console is performed by setting the javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword environment variables when starting it. This can be done at the command line, but the preferred option is to set the configuration within the qpidmc.ini launcher configuration file for repeated usage. This file is equipped with a template to ease configuration, this should be uncommented and edited to suit your needs. It can be found in the root of the console releases for Windows, and Linux. For Mac OS X the file is located within the consoles .app application bundle, and to locate and edit it you must select 'Show Package Contents' when accessing the context menu of the application, then browse to the Contents/MacOS sub folder to locate the file.

JMXMP configuration

Older releases of the Qpid Java server can make use of the Java Management Extensions Messaging Protocol (JMXMP) to provide protection for their JMX connections. This occurs when the server has its main configuration set with the management 'security-enabled' property set to true.

In order to connect to this configuration of server, the console needs an additional library that is not included within the Java SE platform and cannot be distributed with the console due to licensing restrictions.

You can download the JMX Remote API 1.0.1_04 Reference Implementation from the Sun website ???. The included jmxremote-1_0_1-bin/lib/jmxremote_optional.jar file must be added to the plugins/jmxremote.sasl_1.0.1 folder of the console release (again, in Mac OS X you will need to select 'Show package contents' from the context menu whilst selecting the management console bundle in order to reveal the inner file tree).

Following this the console will automatically load the JMX Remote Optional classes and negotiate the SASL authentication profile type when encountering a JMXMP enabled Qpid Java server.

Managing Server Connections

Main Toolbar

The main toolbar of the console can be seen in the image below. The left most buttons respectively allow for adding a new server connection, reconnecting to an existing server selected in the connection tree, disconnecting the selected server connection, and removing the server from the connection tree.

Beside these buttons is a combo for selecting the refresh interval; that is, how often the console requests updated information to display for the currently open area in the main view. Finally, the right-most button enables an immediate update.

Connecting to a new server

To connect to a new server, press the Add New Server toolbar button, or select the Qpid Manager -> Add New Connection menu item. At this point a dialog box will be displayed requesting the server details, namely the server hostname, management port, and a username and password. An example is shown below:

Once all the required details are entered, pressing Connect will initiate a connection attempt to the server. It the attempt fails a reason will be shown and the server will not be added to the connection tree. If the attempt is successful the server will be added to the connections list and the entry expanded to show the initial administration MBeans the user has access to and any VirtualHosts present on the server, as can be seen in the figure below.

If the server supports a newer management API than the console in use, once connected this initial screen will contain a message on the right, indicating an upgraded console should be sought by the user to ensure all management functionality supported by the server is being utilised.

Reconnecting to a server

If a server has been connected to previously, it will be saved as an entry in the connection tree for further use. On subsequent connections the server can simply be selected from the tree and using the Reconnect toolbar button or Qpid Manager -> Reconnect menu item. At this stage the console will prompt simply for the username and password with which the user wishes to connect, and following a successful connection the screen will appear as shown previously above.

Disconnecting from a server

To disconnect from a server, select the connection tree node for the server and press the Disconnect toolbar button, or use the Qpid Manager -> Disconnect menu option.

Removing a server

To remove a server from the connection list, select the connection tree node for the server and press the Remove toolbar button, or use the Qpid Manager -> Remove Connection menu option.

Navigating a connected server

Once connected to a server, the various areas available for administration are accessed using the Qpid Connections tree at the left side of the application. To open a particular MBean from the tree for viewing, simply select it in the tree and it will be opened in the main view.

As there may be vast numbers of Queues, Connections, and Exchanges on the server these MBeans are not automatically added to the tree along with the general administration MBeans. Instead, dedicated selection areas are provided to allow users to select which Queue/Connection/Exchange they wish to view or add to the tree. These areas can be found by clicking on the Connections, Exchanges, and Queues nodes in the tree under each VirtualHost, as shown in the figure above. One or more MBeans may be selected and added to the tree as Favourites using the button provided. These settings are saved for future use, and each time the console connects to the server it will check for the presence of the MBean previously in the tree and add them if they are still present. Queue/Connection/Exchange MBeans can be removed from the tree by right clicking on them to expose a context menu allowing deletion.

As an alternative way to open a particular MBean for viewing, without first adding it to the tree, you can simply double click an entry in the table within the Queue/Connection/Exchange selection areas to open it immediately. It is also possible to open some MBeans like this whilst viewing certain other MBeans. When opening an MBean in either of these ways, a Back button is enabled in the top right corner of the main view. Using this button will return you to the selection area or MBean you were previously viewing. The history resets each time the tree is used to open a new area or MBean.

ConfigurationManagement MBean

The ConfigurationManagement MBean is available on newer servers, to users with admin level management rights. It offers the ability to perform a live reload of the Security sections defined in the main server configuration file (e.g. defaults to: etc/config.xml). This is mainly to allow updating the server Firewall configuration to new settings without a restart, and can be performed by clicking the Execute button and confirming the prompt which follows.

LoggingManagement MBean

The LoggingManagement MBean is available on newer servers, and accessible by admin level users. It allows live alteration of the logging behaviour, both at a Runtime-only level and at the configuration file level. The latter can optionally affect the Runtime configuration, either through use of the servers automated LogWatch ability which detects changes to the configuration file and reloads it, or by manually requesting a reload. This functionality is split across two management tabs, Runtime Options and ConfigurationFile Options.

Runtime Options

The Runtime Options tab allows manipulation of the logging settings without affecting the configuration files (this means the changes will be lost when the server restarts), and gives individual access to every Logger active within the server.

As shown in the figure above, the table in this tab presents the Effective Level of each Logger. This is because the Loggers form a hierarchy in which those without an explicitly defined (in the logging configuration file) Level will inherit the Level of their immediate parent; that is, the Logger whose full name is a prefix of their own, or if none satisfy that condition then the RootLogger is their parent. As example, take the org.apache.qpid Logger. It is parent to all those below it which begin with org.apache.qpid and unless they have a specific Level of their own, they will inherit its Level. This can be seen in the figure, whereby all the children Loggers visible have a level of WARN just like their parent, but the RootLogger Level is INFO; the children have inherited the WARN level from org.apache.qpid rather than INFO from the RootLogger.

To aid with this distinction, the Logger Levels that are currently defined in the configuration file are highlighted in the List. Changing these levels at runtime will also change the Level of all their children which haven't been set their own Level using the runtime options. In the latest versions of the LoggingManagement MBean, it is possible to restore a child logger that has had an explicit level se, to inheriting that of its parent by setting it to an INHERITED level that removes any previously set Level of its own.

In order to set one of more Loggers to a new Level, they should be selected in the table (or double click an individual Logger to modify it) and the Edit Selected Logger(s) button pressed to load the dialog shown above. At this point, any of the available Levels supported by the server can be applied to the Loggers selected and they will immediately update, as will any child Loggers without their own specific Level.

The RootLogger can be similarly edited using the button at the bottom left of the window.

ConfigurationFile Options

The ConfigurationFile Options tab allows alteration of the Level settings for the Loggers defined in the configuration file, allowing changes to persist following a restart of the server. Changes made to the configuration file are only applied automatically while the sever is running if it was configured to enable the LogWatch capability, meaning it will monitor the configuration file for changes and apply the new configuration when the change is detected. If this was not enabled, the changes will be picked up when the server is restarted. The status of the LogWatch feature is shown at the bottom of the tab. Alternatively, in the latest versions of the LoggingManagement MBean it is possible to reload the logging configuration file on demand.

Manipulating the Levels is as on the Runtime Options tab, either double-click an individual Logger entry or select multiple Loggers and use the button to load the dialog to set the new Level.

One issue to note of when reloading the configuration file settings, either automatically using LogWatch or manually, is that any Logger set to a specific Level using the Runtime Options tab that is not defined in the configuration file will maintain that Level when the configuration file is reloaded. In other words, if a Logger is defined in the configuration file, then the configuration file will take precedence at reload, otherwise the Runtime options take precedence.

This situation will be immediately obvious by examining the Runtime Options tab to see the effective Level of each Logger – unless it has been altered with the RuntimeOptions or specifically set in the configuration file, a Logger Level should match that of its parent. In the latest versions of the LoggingManagement MBean, it is possible to use the RuntimeOptions to restore a child logger to inheriting from its parent by setting it with an INHERITED level that removes any previously set Level of its own.

ServerInformation MBean

The ServerInformation MBean currently only conveys various pieces of version information to allow precise identification of the server version and its management capabilities. In future it is likely to convey additional server-wide details and/or functionality.

UserManagement MBean

The UserManagement MBean is accessible by admin level users, and allows manipulation of existing user accounts and creation of new user accounts.

To add a new user, press the Add New User button, which will load the dialog shown below.

Here you may enter the new users Username, Password, and select their JMX Management Rights. This controls whether or not they have access to the management interface, and if so what capabilities are accessible. Read Only access allows undertaking any operations that do not alter the server state, such as viewing messages. Read + Write access allows use of all operations which are not deemed admin-only (such as those in the UserManagement MBean itself). Admin access allows a user to utilize any operation, and view the admin-only MBeans (currently these are ConfigurationManagement, LoggingManagement, and UserManagement).

One or more users at a time may be deleted by selecting them in the table and clicking the Delete User(s) button. The console will then prompt for confirmation before undertaking the removals. Similarly, the access rights for one or more users may be updated by selecting them in the table and clicking the Set Rights button. The console will then display a dialog enabling selection of the new access level and confirmation to undertake the update.

An individual user password may be updated by selecting the user in the table in and clicking the Set Password button. The console will then display a dialog enabling input of the new password and confirmation to undertake the update.

The server caches the user details in memory to aid performance. If may sometimes be necessary to externally modify the password and access right files on disk. In order for these changes to be known to the server without a restart, it must be instructed to reload the file contents. This can be done using the provided Reload User Details button (on older servers, only the management rights file is reloaded, on newer servers both files are. The description on screen will indicate the behaviour). After pressing this button the console will seek confirmation before proceeding.

VirtualHostManager MBean

Each VirtualHost in the server has an associated VirtualHostManager MBean. This allows viewing, creation, and deletion of Queues and Exchanges within the VirtualHost.

Clicking the Create button in the Queue section will open a dialog allowing specification of the Name, Owner (optional), and durability properties of the new Queue, and confirmation of the operation.

One or more Queues may be deleted by selecting them in the table and clicking the Delete button. This will unregister the Queue bindings, remove the subscriptions and delete the Queue(s). The console will prompt for confirmation before undertaking the operation.

Clicking the Create button in the Exchange section will open a dialog allowing specification of the Name, Type, and Durable attributes of the new Exchange, and confirmation of the operation.

One or more Exchanges may be deleted by selecting them in the table and clicking the Delete button. This will unregister all the related channels and Queue bindings then delete the Exchange(s). The console will prompt for confirmation before undertaking the operation.

Double-clicking on a particular Queue or Exchange name in the tables will open the MBean representing it.

Notifications

MBeans on the server can potentially send Notifications that users may subscribe to. When managing an individual MBean that offers Notifications types for subscription, the console supplies a Notifications tab to allow (un)subscription to the Notifications if desired and viewing any that are received following subscription.

In order to provide quicker access to/awareness of any received Notifications, each VirtualHost area in the connection tree has a Notifications area that aggregates all received Notifications for MBeans in that VirtualHost. An example of this can be seen in the figure below.

All received Notifications will be displayed until such time as the user removes them, either in this aggregated view, or in the Notifications area of the individual MBean that generated the Notification.

They may be cleared selectively or all at once. To clear particular Notifications, they should be selected in the table before pressing the Clear button. To clear all Notifications, simply press the Clear button without anything selected in the table, at which point the console will request confirmation of this clear-all action.

Managing Queues

As mentioned in earlier discussion of Navigation, Queue MBeans can be opened either by double clicking an entry in the Queues selection area, or adding a queue to the tree as a favourite and clicking on its tree node. Unique to the Queue selection screen is the ability to view additional attributes beyond just that of the Queue Name. This is helpful for determining which Queues satisfy a particular condition, e.g. having <X> messages on the queue. The example below shows the selection view with additional attributes Consumer Count, Durable, MessageCount, and QueueDepth (selected using the Select Attributes button at the bottom right corner of the table).

Upon opening a Queue MBean, the Attributes tab is displayed, as shown below. This allows viewing the value all attributes, editing those which are writable values (highlighted in blue) if the users management permissions allow, viewing descriptions of their purpose, and graphing certain numerical attribute values as they change over time.

The next tab contains the operations that can be performed on the queue. The main table serves as a means of viewing the messages on the queue, and later for selecting specific messages to operate upon. It is possible to view any desired range of messages on the queue by specifying the visible range using the fields at the top and pressing the Set button. Next to this there are helper buttons to enable faster browsing through the messages on the queue; these allow moving forward and back by whatever number of messages is made visible by the viewing range set. The Queue Position column indicates the position of each message on the queue, but is only present when connected to newer servers as older versions cannot provide the necessary information to show this (unless only a single message position is requested).

Upon selecting a message in the table, its header properties and redelivery status are updated in the area below the table. Double clicking a message in the table (or using the View Message Content button to its right) will open a dialog window displaying the contents of the message.

One or more messages can be selected in the table and moved to another queue in the VirtualHost by using the Move Message(s) button, which opens a dialog to enable selection of the destination and confirmation of the operation. Newer servers support the ability to similarly copy the selected messages to another queue in a similar fashion, or delete the selected messages from the queue after prompting for confirmation.

Finally, all messages (that have not been acquired by consumers) on the queue can be deleted using the Clear Queue button, which will generate a prompt for confirmation. On newer servers, the status bar at the lower left of the application will report the number of messages actually removed.

Managing Exchanges

Exchange MBeans are opened for management operations in similar fashion as described for Queues, again showing an Attributes tab initially, with the Operations tab next:

Of the four default Exchange Types (direct, fanout, headers, and topic) all but headers have their bindings presented in the format shown above. The left table provides the binding/routing keys present in the exchange. Selecting one of these entries in the table prompts the right table to display all the queues associated with this key. Pressing the Create button opens a dialog allowing association of an existing queue with the entered Binding.

The headers Exchange type (default instantiation amq.match or amq.headers) is presented as below:

In the previous figure, the left table indicates the binding number, and the Queue associated with the binding. Selecting one of these entries in the table prompts the right table to display the header values that control when the binding matches an incoming message.

Pressing the Create button when managing a headers Exchange opens a dialog allowing creation of a new binding, associating an existing Queue with a particular set of header keys and values. The x-match key is required, and instructs the server whether to match the binding with incoming messages based on ANY or ALL of the further key-value pairs entered. If it is desired to enter more than 4 pairs, you may press the Add additional field button to create a new row as many times as is required. When managing a headers Exchange, double clicking an entry in the left-hand table will open the MBean for the Queue specified in the binding properties.

When managing another Exchange Type, double clicking the Queue Name in the right-hand table will open the MBean of the Queue specified.

Managing Connections

Exchange MBeans are opened for management operations in similar fashion as described for Queues, again showing an Attributes tab initially, with the Operations tab next, and finally a Notifications tab allowing subscription and viewing of Notifications. The Operations tab can be seen in the figure below.

The main table shows the properties of all the Channels that are present on the Connection, including whether they are Transactional, the Number of Unacked Messages on them, and the Default Queue if there is one (or null if there is not).

The main operations supported on a connection are Commiting and Rolling Back of Transactions on a particular Channel, if the Channel is Transactional. This can be done by selecting a particular Channel in the table and pressing the Commit Transactions or Rollback Transactions buttons at the lower right corner of the table, at which point the console will prompt for confirmation of the action. These buttons are only active when the selected Channel in the table is Transactional.

The final operation supported is closing the Connection. After pressing the Close Connection button, the console will prompt for confirmation of the action. If this is carried out, the MBean for the Connection being managed will be removed from the server. The console will be notified of this by the server and display an information dialog to that effect, as it would if any other MBean were to be unregistered whilst being viewed.

Double clicking a row in the table will open the MBean of the associated Default Queue if there is one.

3.1.1.6.  Qpid Management Features

Management tool: See our ??? for details of how to use various console options with the Qpid management features.

The management of QPID is categorised into following types-

  1. Exchange

  2. Queue

  3. Connection

  4. Broker

 1) Managing and Monitoring Exchanges: Following is the list of features, which we can have available for managing and monitoring an Exchange running on a Qpid Server Domain-

  1. Displaying the following information for monitoring purpose-

    1. The list of queues bound to the exchange along with the routing keys.

    2. General Exchange properties(like name, durable etc).

  2. Binding an existing queue with the exchange.

2) Managing and Monitoring Queues:  Following are the features, which we can have for a Queue on a Qpid Server Domain-

  1. Displaying the following information about the queue for monitoring purpose-

    1. General Queue properties(like name, durable, etc.)

    2. The maximum size of a message that can be accepted from the message producer.

    3. The number of the active consumers accessing the Queue.

    4. The total number of consumers (Active and Suspended).

    5. The number of undelivered messages in the Queue.

    6. The total number of messages received on the Queue since startup.

    7. The maximum number of bytes for the Queue that can be stored on the Server.

    8. The maximum number of messages for the Queue that can be stored on the Server.

  2. Viewing the messages on the Queue.

  3. Deleting message from top of the Queue.

  4. Clearing the Queue.

  5. Browsing the DeadMessageQueue - Messages which are expired or undelivered because of some reason are routed to the DeadMessageQueue.  This queue can not be deleted.  [Note: The is open because it depends on how these kind of messages will be handeled?]

3) Managing and Monitoring Connections: Following are the features, which we can have for a connection on a QPID Server Domain-

  1. Displaying general connection properties(like remote address, etc.).

  2. Setting maximum number of channels allowed for a connection.

  3. View all related channels and channel properties.

  4. Closing a channel.

  5. Commit or Rollback transactions of a channel, if the channel is transactional.

  6. Notification for exceeding the maximum number of channels.

  7. Dropping a connection.

  8. The work for ??? implies that there are potentially some additional requirements

    1. Alert when tcp flow control kicks in

    2. Information available about current memory usage available through JMX interface

    3. Dynamic removal of buffer bounds? (fundamentally not possible with TransportIO)

    4. Management functionality added to JMX interface - UI changes?

4) Managing the Broker: Features for the Broker-

  1. Creating an Exchange.

  2. Unregistering an Exchange.

  3. Creating a Queue.

  4. Deleting a Queue.