HornetQ has an extensive management API that allows a user to modify a server configuration, create new resources (e.g. JMS queues and topics), inspect these resources (e.g. how many messages are currently held in a queue) and interact with it (e.g. to remove messages from a queue). All the operations allows a client to manage HornetQ. It also allows clients to subscribe to management notifications.
There are 3 ways to manage HornetQ:
Using JMX -- JMX is the standard way to manage Java applications
Using the core API -- management operations are sent to HornetQ server using core messages
Using the JMS API -- management operations are sent to HornetQ server using JMS messages
Although there are 3 different ways to manage HornetQ each API supports the same functionality. If it is possible to manage a resource using JMX it is also possible to achieve the same result using Core messages or JMS messages.
This choice depends on your requirements, your application settings and your environment to decide which way suits you best.
Regardless of the way you invoke management operations, the management API is the same.
For each managed resource, there exists a Java interface describing what can be invoked for this type of resource.
HornetQ exposes its managed resources in 2 packages:
Core resources are located in the
org.hornetq.api.core.managementpackageJMS resources are located in the
org.hornetq.api.jms.managementpackage
The way to invoke a management operations depends whether JMX, core messages, or JMS messages are used.
Note
A few management operations requires a filter parameter to chose
which messages are involved by the operation. Passing null or an
empty string means that the management operation will be performed on all
messages.
HornetQ defines a core management API to manage core resources. For full details of the API please consult the javadoc. In summary:
Listing, creating, deploying and destroying queues
A list of deployed core queues can be retrieved using the
getQueueNames()method.Core queues can be created or destroyed using the management operations
createQueue()ordeployQueue()ordestroyQueue())on theHornetQServerControl(with the ObjectNameorg.hornetq:module=Core,type=Serveror the resource namecore.server)createQueuewill fail if the queue already exists whiledeployQueuewill do nothing.Pausing and resuming Queues
The
QueueControlcan pause and resume the underlying queue. When a queue is paused, it will receive messages but will not deliver them. When it's resumed, it'll begin delivering the queued messages, if any.Listing and closing remote connections
Client's remote addresses can be retrieved using
listRemoteAddresses(). It is also possible to close the connections associated with a remote address using thecloseConnectionsForAddress()method.Alternatively, connection IDs can be listed using
listConnectionIDs()and all the sessions for a given connection ID can be listed usinglistSessions().Transaction heuristic operations
In case of a server crash, when the server restarts, it it possible that some transaction requires manual intervention. The
listPreparedTransactions()method lists the transactions which are in the prepared states (the transactions are represented as opaque Base64 Strings.) To commit or rollback a given prepared transaction, thecommitPreparedTransaction()orrollbackPreparedTransaction()method can be used to resolve heuristic transactions. Heuristically completed transactions can be listed using thelistHeuristicCommittedTransactions()andlistHeuristicRolledBackTransactionsmethods.Enabling and resetting Message counters
Message counters can be enabled or disabled using the
enableMessageCounters()ordisableMessageCounters()method. To reset message counters, it is possible to invokeresetAllMessageCounters()andresetAllMessageCounterHistories()methods.Retrieving the server configuration and attributes
The
HornetQServerControlexposes HornetQ server configuration through all its attributes (e.g.getVersion()method to retrieve the server's version, etc.)Listing, creating and destroying Core bridges and diverts
A list of deployed core bridges (resp. diverts) can be retrieved using the
getBridgeNames()(resp.getDivertNames()) method.Core bridges (resp. diverts) can be created or destroyed using the management operations
createBridge()anddestroyBridge()(resp.createDivert()anddestroyDivert()) on theHornetQServerControl(with the ObjectNameorg.hornetq:module=Core,type=Serveror the resource namecore.server).It is possible to stop the server and force failover to occur with any currently attached clients.
to do this use the
forceFailover()on theHornetQServerControl(with the ObjectNameorg.hornetq:module=Core,type=Serveror the resource namecore.server)Note
Since this method actually stops the server you will probably receive some sort of error depending on which management service you use to call it.
Core addresses can be managed using the AddressControl class
(with the ObjectName org.hornetq:module=Core,type=Address,name="<the
address name>" or the resource name core.address.<the
address name>).
Modifying roles and permissions for an address
You can add or remove roles associated to a queue using the
addRole()orremoveRole()methods. You can list all the roles associated to the queue with thegetRoles()method
The bulk of the core management API deals with core queues. The QueueControl class defines the Core queue management operations (with
the ObjectName org.hornetq:module=Core,type=Queue,address="<the bound
address>",name="<the queue name>" or the resource name core.queue.<the queue name>).
Most of the management operations on queues take either a single message ID (e.g. to remove a single message) or a filter (e.g. to expire all messages with a given property.)
Expiring, sending to a dead letter address and moving messages
Messages can be expired from a queue by using the
expireMessages()method. If an expiry address is defined, messages will be sent to it, otherwise they are discarded. The queue's expiry address can be set with thesetExpiryAddress()method.Messages can also be sent to a dead letter address with the
sendMessagesToDeadLetterAddress()method. It returns the number of messages which are sent to the dead letter address. If a dead letter address is not defined, message are removed from the queue and discarded. The queue's dead letter address can be set with thesetDeadLetterAddress()method.Messages can also be moved from a queue to another queue by using the
moveMessages()method.Listing and removing messages
Messages can be listed from a queue by using the
listMessages()method which returns an array ofMap, oneMapfor each message.Messages can also be removed from the queue by using the
removeMessages()method which returns abooleanfor the single message ID variant or the number of removed messages for the filter variant. TheremoveMessages()method takes afilterargument to remove only filtered messages. Setting the filter to an empty string will in effect remove all messages.Counting messages
The number of messages in a queue is returned by the
getMessageCount()method. Alternatively, thecountMessages()will return the number of messages in the queue which match a given filterChanging message priority
The message priority can be changed by using the
changeMessagesPriority()method which returns abooleanfor the single message ID variant or the number of updated messages for the filter variant.Message counters
Message counters can be listed for a queue with the
listMessageCounter()andlistMessageCounterHistory()methods (see Section 30.6, “Message Counters”). The message counters can also be reset for a single queue using theresetMessageCounter()method.Retrieving the queue attributes
The
QueueControlexposes Core queue settings through its attributes (e.g.getFilter()to retrieve the queue's filter if it was created with one,isDurable()to know whether the queue is durable or not, etc.)Pausing and resuming Queues
The
QueueControlcan pause and resume the underlying queue. When a queue is paused, it will receive messages but will not deliver them. When it's resume, it'll begin delivering the queued messages, if any.
HornetQ allows to start and stop its remote resources (acceptors, diverts, bridges, etc.) so that a server can be taken off line for a given period of time without stopping it completely (e.g. if other management operations must be performed such as resolving heuristic transactions). These resources are:
Acceptors
They can be started or stopped using the
start()or.stop()method on theAcceptorControlclass (with the ObjectNameorg.hornetq:module=Core,type=Acceptor,name="<the acceptor name>"or the resource namecore.acceptor.<the address name>). The acceptors parameters can be retrieved using theAcceptorControlattributes (see Section 16.1, “Understanding Acceptors”)Diverts
They can be started or stopped using the
start()orstop()method on theDivertControlclass (with the ObjectNameorg.hornetq:module=Core,type=Divert,name=<the divert name>or the resource namecore.divert.<the divert name>). Diverts parameters can be retrieved using theDivertControlattributes (see Chapter 35, Diverting and Splitting Message Flows)Bridges
They can be started or stopped using the
start()(resp.stop()) method on theBridgeControlclass (with the ObjectNameorg.hornetq:module=Core,type=Bridge,name="<the bridge name>"or the resource namecore.bridge.<the bridge name>). Bridges parameters can be retrieved using theBridgeControlattributes (see Chapter 36, Core Bridges)Broadcast groups
They can be started or stopped using the
start()orstop()method on theBroadcastGroupControlclass (with the ObjectNameorg.hornetq:module=Core,type=BroadcastGroup,name="<the broadcast group name>"or the resource namecore.broadcastgroup.<the broadcast group name>). Broadcast groups parameters can be retrieved using theBroadcastGroupControlattributes (see Section 38.2.1.1, “Broadcast Groups”)Discovery groups
They can be started or stopped using the
start()orstop()method on theDiscoveryGroupControlclass (with the ObjectNameorg.hornetq:module=Core,type=DiscoveryGroup,name="<the discovery group name>"or the resource namecore.discovery.<the discovery group name>). Discovery groups parameters can be retrieved using theDiscoveryGroupControlattributes (see Section 38.2.1.2, “Discovery Groups”)Cluster connections
They can be started or stopped using the
start()orstop()method on theClusterConnectionControlclass (with the ObjectNameorg.hornetq:module=Core,type=ClusterConnection,name="<the cluster connection name>"or the resource namecore.clusterconnection.<the cluster connection name>). Cluster connections parameters can be retrieved using theClusterConnectionControlattributes (see Section 38.3.1, “Configuring Cluster Connections”)
HornetQ defines a JMS Management API to manage JMS administrated objects (i.e. JMS queues, topics and connection factories).
JMS Resources (connection factories and destinations) can be created using the
JMSServerControl class (with the ObjectName org.hornetq:module=JMS,type=Server or the resource name jms.server).
Listing, creating, destroying connection factories
Names of the deployed connection factories can be retrieved by the
getConnectionFactoryNames()method.JMS connection factories can be created or destroyed using the
createConnectionFactory()methods ordestroyConnectionFactory()methods. These connection factories are bound to JNDI so that JMS clients can look them up. If a graphical console is used to create the connection factories, the transport parameters are specified in the text field input as a comma-separated list of key=value (e.g.key1=10, key2="value", key3=false). If there are multiple transports defined, you need to enclose the key/value pairs between curly braces. For example{key=10}, {key=20}. In that case, the firstkeywill be associated to the first transport configuration and the secondkeywill be associated to the second transport configuration (see Chapter 16, Configuring the Transport for a list of the transport parameters)Listing, creating, destroying queues
Names of the deployed JMS queues can be retrieved by the
getQueueNames()method.JMS queues can be created or destroyed using the
createQueue()methods ordestroyQueue()methods. These queues are bound to JNDI so that JMS clients can look them upListing, creating/destroying topics
Names of the deployed topics can be retrieved by the
getTopicNames()method.JMS topics can be created or destroyed using the
createTopic()ordestroyTopic()methods. These topics are bound to JNDI so that JMS clients can look them upListing and closing remote connections
JMS Clients remote addresses can be retrieved using
listRemoteAddresses(). It is also possible to close the connections associated with a remote address using thecloseConnectionsForAddress()method.Alternatively, connection IDs can be listed using
listConnectionIDs()and all the sessions for a given connection ID can be listed usinglistSessions().
JMS Connection Factories can be managed using the ConnectionFactoryControl class (with the ObjectName org.hornetq:module=JMS,type=ConnectionFactory,name="<the connection factory
name>" or the resource name jms.connectionfactory.<the
connection factory name>).
Retrieving connection factory attributes
The
ConnectionFactoryControlexposes JMS ConnectionFactory configuration through its attributes (e.g.getConsumerWindowSize()to retrieve the consumer window size for flow control,isBlockOnNonDurableSend()to know whether the producers created from the connection factory will block or not when sending non-durable messages, etc.)
JMS queues can be managed using the JMSQueueControl class (with
the ObjectName org.hornetq:module=JMS,type=Queue,name="<the queue
name>" or the resource name jms.queue.<the queue
name>).
The management operations on a JMS queue are very similar to the operations on a core queue.
Expiring, sending to a dead letter address and moving messages
Messages can be expired from a queue by using the
expireMessages()method. If an expiry address is defined, messages will be sent to it, otherwise they are discarded. The queue's expiry address can be set with thesetExpiryAddress()method.Messages can also be sent to a dead letter address with the
sendMessagesToDeadLetterAddress()method. It returns the number of messages which are sent to the dead letter address. If a dead letter address is not defined, message are removed from the queue and discarded. The queue's dead letter address can be set with thesetDeadLetterAddress()method.Messages can also be moved from a queue to another queue by using the
moveMessages()method.Listing and removing messages
Messages can be listed from a queue by using the
listMessages()method which returns an array ofMap, oneMapfor each message.Messages can also be removed from the queue by using the
removeMessages()method which returns abooleanfor the single message ID variant or the number of removed messages for the filter variant. TheremoveMessages()method takes afilterargument to remove only filtered messages. Setting the filter to an empty string will in effect remove all messages.Counting messages
The number of messages in a queue is returned by the
getMessageCount()method. Alternatively, thecountMessages()will return the number of messages in the queue which match a given filterChanging message priority
The message priority can be changed by using the
changeMessagesPriority()method which returns abooleanfor the single message ID variant or the number of updated messages for the filter variant.Message counters
Message counters can be listed for a queue with the
listMessageCounter()andlistMessageCounterHistory()methods (see Section 30.6, “Message Counters”)Retrieving the queue attributes
The
JMSQueueControlexposes JMS queue settings through its attributes (e.g.isTemporary()to know whether the queue is temporary or not,isDurable()to know whether the queue is durable or not, etc.)Pausing and resuming queues
The
JMSQueueControlcan pause and resume the underlying queue. When the queue is paused it will continue to receive messages but will not deliver them. When resumed again it will deliver the enqueued messages, if any.
JMS Topics can be managed using the TopicControl class (with
the ObjectName org.hornetq:module=JMS,type=Topic,name="<the topic
name>" or the resource name jms.topic.<the topic
name>).
Listing subscriptions and messages
JMS topics subscriptions can be listed using the
listAllSubscriptions(),listDurableSubscriptions(),listNonDurableSubscriptions()methods. These methods return arrays ofObjectrepresenting the subscriptions information (subscription name, client ID, durability, message count, etc.). It is also possible to list the JMS messages for a given subscription with thelistMessagesForSubscription()method.Dropping subscriptions
Durable subscriptions can be dropped from the topic using the
dropDurableSubscription()method.Counting subscriptions messages
The
countMessagesForSubscription()method can be used to know the number of messages held for a given subscription (with an optional message selector to know the number of messages matching the selector)
HornetQ can be managed using JMX.
The management API is exposed by HornetQ using MBeans interfaces. HornetQ registers its
resources with the domain org.hornetq.
For example, the ObjectName to manage a JMS Queue exampleQueue is:
org.hornetq:module=JMS,type=Queue,name="exampleQueue"
and the MBean is:
org.hornetq.api.jms.management.JMSQueueControl
The MBean's ObjectName are built using the helper class org.hornetq.api.core.management.ObjectNameBuilder. You can also use jconsole to find the ObjectName of the MBeans you want to
manage.
Managing HornetQ using JMX is identical to management of any Java Applications using JMX. It can be done by reflection or by creating proxies of the MBeans.
By default, JMX is enabled to manage HornetQ. It can be disabled by setting jmx-management-enabled to false in hornetq-configuration.xml:
<!-- false to disable JMX management for HornetQ -->
<jmx-management-enabled>false</jmx-management-enabled>
If JMX is enabled, HornetQ can be managed locally using jconsole.
Note
Remote connections to JMX are not enabled by default for security reasons. Please refer
to Java Management guide to configure the server for remote management (system
properties must be set in run.sh or run.bat
scripts).
By default, HornetQ server uses the JMX domain "org.hornetq". To manage several
HornetQ servers from the same MBeanServer, the JMX domain can be
configured for each individual HornetQ server by setting jmx-domain
in hornetq-configuration.xml:
<!-- use a specific JMX domain for HornetQ MBeans -->
<jmx-domain>my.org.hornetq</jmx-domain>
When HornetQ is run in standalone, it uses the Java Virtual Machine's Platform MBeanServer to register its MBeans. This is configured in
JBoss Microcontainer Beans file (see Section 6.7, “JBoss Microcontainer Beans File”):
<!-- MBeanServer -->
<bean name="MBeanServer" class="javax.management.MBeanServer">
<constructor factoryClass="java.lang.management.ManagementFactory"
factoryMethod="getPlatformMBeanServer" />
</bean>
When it is integrated in JBoss AS 5+, it uses the Application Server's own MBean Server so that it can be managed using AS 5's jmx-console:
<!-- MBeanServer -->
<bean name="MBeanServer" class="javax.management.MBeanServer">
<constructor factoryClass="org.jboss.mx.util.MBeanServerLocator"
factoryMethod="locateJBoss" />
</bean>
See Section 11.1.28, “JMX Management” for an example which shows how to use a remote connection to JMX and MBean proxies to manage HornetQ.
The core management API in HornetQ is called by sending Core messages to a special address, the management address.
Management messages are regular Core messages with well-known properties that the server needs to understand to interact with the management API:
The name of the managed resource
The name of the management operation
The parameters of the management operation
When such a management message is sent to the management address, HornetQ server will
handle it, extract the information, invoke the operation on the managed resources and send
a management reply to the management message's reply-to address
(specified by ClientMessageImpl.REPLYTO_HEADER_NAME).
A ClientConsumer can be used to consume the management reply and
retrieve the result of the operation (if any) stored in the reply's body. For portability,
results are returned as a JSON String rather than Java
Serialization (the org.hornetq.api.core.management.ManagementHelper can
be used to convert the JSON string to Java objects).
These steps can be simplified to make it easier to invoke management operations using Core messages:
Create a
ClientRequestorto send messages to the management address and receive repliesCreate a
ClientMessageUse the helper class
org.hornetq.api.core.management.ManagementHelperto fill the message with the management propertiesSend the message using the
ClientRequestorUse the helper class
org.hornetq.api.core.management.ManagementHelperto retrieve the operation result from the management reply
For example, to find out the number of messages in the core queue exampleQueue:
ClientSession session = ...
ClientRequestor requestor = new ClientRequestor(session, "jms.queue.hornetq.management");
ClientMessage message = session.createMessage(false);
ManagementHelper.putAttribute(message, "core.queue.exampleQueue", "messageCount");
ClientMessage reply = requestor.request(m);
int count = (Integer) ManagementHelper.getResult(reply);
System.out.println("There are " + count + " messages in exampleQueue");
Management operation name and parameters must conform to the Java interfaces defined in
the management packages.
Names of the resources are built using the helper class org.hornetq.api.core.management.ResourceNames and are straightforward
(core.queue.exampleQueue for the Core Queue exampleQueue, jms.topic.exampleTopic for the JMS Topic
exampleTopic, etc.).
The management address to send management messages is configured in hornetq-configuration.xml:
<management-address>jms.queue.hornetq.management</management-address>
By default, the address is jms.queue.hornetq.management (it is
prepended by "jms.queue" so that JMS clients can also send management messages).
The management address requires a special user permission
manage to be able to receive and handle management messages. This
is also configured in hornetq-configuration.xml:
<!-- users with the admin role will be allowed to manage -->
<!-- HornetQ using management messages -->
<security-setting match="jms.queue.hornetq.management">
<permission type="manage" roles="admin" />
</security-setting>
Using JMS messages to manage HornetQ is very similar to using core API.
An important difference is that JMS requires a JMS queue to send the messages to (instead of an address for the core API).
The management queue is a special queue and needs to be instantiated directly by the client:
Queue managementQueue = HornetQJMSClient.createQueue("hornetq.management");
All the other steps are the same than for the Core API but they use JMS API instead:
create a
QueueRequestorto send messages to the management address and receive repliescreate a
Messageuse the helper class
org.hornetq.api.jms.management.JMSManagementHelperto fill the message with the management propertiessend the message using the
QueueRequestoruse the helper class
org.hornetq.api.jms.management.JMSManagementHelperto retrieve the operation result from the management reply
For example, to know the number of messages in the JMS queue exampleQueue:
Queue managementQueue = HornetQJMSClient.createQueue("hornetq.management");
QueueSession session = ...
QueueRequestor requestor = new QueueRequestor(session, managementQueue);
connection.start();
Message message = session.createMessage();
JMSManagementHelper.putAttribute(message, "jms.queue.exampleQueue", "messageCount");
Message reply = requestor.request(message);
int count = (Integer)JMSManagementHelper.getResult(reply);
System.out.println("There are " + count + " messages in exampleQueue");
Whether JMS or the core API is used for management, the configuration steps are the same (see Section 30.3.1, “Configuring Core Management”).
See Section 11.1.31, “Management” for an example which shows how to use JMS messages to manage HornetQ server.
HornetQ emits notifications to inform listeners of potentially interesting events (creation of new resources, security violation, etc.).
These notifications can be received by 3 different ways:
JMX notifications
Core messages
JMS messages
If JMX is enabled (see Section 30.2.1, “Configuring JMX”), JMX notifications can be received by subscribing to 2 MBeans:
org.hornetq:module=Core,type=Serverfor notifications on Core resourcesorg.hornetq:module=JMS,type=Serverfor notifications on JMS resources
HornetQ defines a special management notification address. Core queues can be bound to this address so that clients will receive management notifications as Core messages
A Core client which wants to receive management notifications must create a core queue bound to the management notification address. It can then receive the notifications from its queue.
Notifications messages are regular core messages with additional properties corresponding to the notification (its type, when it occurred, the resources which were concerned, etc.).
Since notifications are regular core messages, it is possible to use message selectors to filter out notifications and receives only a subset of all the notifications emitted by the server.
The management notification address to receive management notifications is
configured in hornetq-configuration.xml:
<management-notification-address>hornetq.notifications</management-notification-address>
By default, the address is hornetq.notifications.
HornetQ's notifications can also be received using JMS messages.
It is similar to receiving notifications using Core API but an important difference is that JMS requires a JMS Destination to receive the messages (preferably a Topic).
To use a JMS Destination to receive management notifications, you must change the server's
management notification address to start with jms.queue if it is a JMS Queue
or jms.topic if it is a JMS Topic:
<!-- notifications will be consumed from "notificationsTopic" JMS Topic -->
<management-notification-address>jms.topic.notificationsTopic</management-notification-address>
Once the notification topic is created, you can receive messages from it or set a
MessageListener:
Topic notificationsTopic = HornetQJMSClient.createTopic("notificationsTopic");
Session session = ...
MessageConsumer notificationConsumer = session.createConsumer(notificationsTopic);
notificationConsumer.setMessageListener(new MessageListener()
{
public void onMessage(Message notif)
{
System.out.println("------------------------");
System.out.println("Received notification:");
try
{
Enumeration propertyNames = notif.getPropertyNames();
while (propertyNames.hasMoreElements())
{
String propertyName = (String)propertyNames.nextElement();
System.out.format(" %s: %s\n", propertyName, notif.getObjectProperty(propertyName));
}
}
catch (JMSException e)
{
}
System.out.println("------------------------");
}
});
See Section 11.1.32, “Management Notification” for an example which shows
how to use a JMS MessageListener to receive management notifications
from HornetQ server.
Message counters can be used to obtain information on queues over time as HornetQ keeps a history on queue metrics.
They can be used to show trends on queues. For example, using the management API, it would be possible to query the number of messages in a queue at regular interval. However, this would not be enough to know if the queue is used: the number of messages can remain constant because nobody is sending or receiving messages from the queue or because there are as many messages sent to the queue than messages consumed from it. The number of messages in the queue remains the same in both cases but its use is widely different.
Message counters gives additional information about the queues:
countThe total number of messages added to the queue since the server was started
countDeltathe number of messages added to the queue since the last message counter update
depthThe current number of messages in the queue
depthDeltaThe overall number of messages added/removed from the queue since the last message counter update. For example, if
depthDeltais equal to-10this means that overall 10 messages have been removed from the queue (e.g. 2 messages were added and 12 were removed)lastAddTimestampThe timestamp of the last time a message was added to the queue
udpateTimestampThe timestamp of the last message counter update
By default, message counters are disabled as it might have a small negative effect on memory.
To enable message counters, you can set it to true in hornetq-configuration.xml:
<message-counter-enabled>true</message-counter-enabled>
Message counters keeps a history of the queue metrics (10 days by default) and
samples all the queues at regular interval (10 seconds by default). If message counters
are enabled, these values should be configured to suit your messaging use case in
hornetq-configuration.xml:
<!-- keep history for a week -->
<message-counter-max-day-history>7</message-counter-max-day-history>
<!-- sample the queues every minute (60000ms) -->
<message-counter-sample-period>60000</message-counter-sample-period>
Message counters can be retrieved using the Management API. For example, to retrieve message counters on a JMS Queue using JMX:
// retrieve a connection to HornetQ's MBeanServer
MBeanServerConnection mbsc = ...
JMSQueueControlMBean queueControl = (JMSQueueControl)MBeanServerInvocationHandler.newProxyInstance(mbsc,
on,
JMSQueueControl.class,
false);
// message counters are retrieved as a JSON String
String counters = queueControl.listMessageCounter();
// use the MessageCounterInfo helper class to manipulate message counters more easily
MessageCounterInfo messageCounter = MessageCounterInfo.fromJSON(counters);
System.out.format("%s message(s) in the queue (since last sample: %s)\n",
counter.getDepth(),
counter.getDepthDelta());
See Section 11.1.33, “Message Counter” for an example which shows how to use
message counters to retrieve information on a JMS Queue.
Its possible to create and configure HornetQ resources via the admin console within the JBoss Application Server.
The Admin Console will allow you to create destinations (JMS Topics and Queues) and JMS Connection Factories.
Once logged in to the admin console you will see a JMS Manager item in the left hand tree. All HornetQ resources will be configured via this. This will have a child items for JMS Queues, Topics and Connection Factories, clicking on each node will reveal which resources are currently available. The following sections explain how to create and configure each resource in turn.
To create a new JMS Queue click on the JMS Queues item to reveal the available queues. On the right hand panel you will see an add a new resource button, click on this and then choose the default(JMS Queue) template and click continue. The important things to fill in here are the name of the queue and the JNDI name of the queue. The JNDI name is what you will use to look up the queue in JNDI from your client. For most queues this will be the only info you will need to provide as sensible defaults are provided for the others. You will also see a security roles section near the bottom. If you do not provide any roles for this queue then the servers default security configuration will be used, after you have created the queue these will be shown in the configuration. All configuration values, except the name and JNDI name, can be changed via the configuration tab after clicking on the queue in the admin console. The following section explains these in more detail
After highlighting the configuration you will see the following screen
The name and JNDI name cant be changed, if you want to change these recreate the queue with the appropriate settings. The rest of the configuration options, apart from security roles, relate to address settings for a particular address. The default address settings are picked up from the servers configuration, if you change any of these settings or create a queue via the console a new Address Settings enrty will be added. For a full explanation on Address Settings see Section 25.3, “Configuring Queues Via Address Settings”
To delete a queue simply click on the delete button beside the queue name in the main JMS Queues screen. This will also delete any address settings or security settings previously created for the queues address
The last part of the configuration options are security roles. If non are provided on creation then the servers default security settings will be shown. If these are changed or updated then new securty settings are created for the address of this queue. For more information on securuty setting see Chapter 31, Security
It is also possible via the metrics tab to view statistics for this queue. This will show statistics such as message count, consumer count etc.
Operations can be performed on a queue via the control tab. This will allow you to start and stop the queue, list,move,expire and delete messages from the queue and other useful operations. To invoke an operation click on the button for the operation you want, this will take you to a screen where you can parameters for the opertion can be set. Once set clicking the ok button will invoke the operation, results appear at the bottom of the screen.
Creating and configuring JMS Topics is almost identical to creating queues. The only difference is that the configuration will be applied to the queue representing a subscription.