Questo contenuto non è disponibile nella lingua selezionata.
Chapter 5. Using the management API
AMQ Broker has an extensive management API, which you can use to modify a broker’s configuration, create new resources (for example, addresses and queues), inspect these resources (for example, how many messages are currently held in a queue), and interact with them (for example, to remove messages from a queue).
In addition, clients can use the management API to manage the broker and subscribe to management notifications.
5.1. Methods for managing AMQ Broker using the management API
There are two ways to use the management API to manage the broker:
- Using JMX — JMX is the standard way to manage Java applications
- Using the JMS API — management operations are sent to the broker using JMS messages and the AMQ JMS client
Although there are two different ways to manage the broker, 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 by using JMS messages and the AMQ JMS client.
This choice depends on your particular requirements, application settings, and environment. 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. The broker exposes its managed resources in the org.apache.activemq.artemis.api.core.management package. The way to invoke management operations depends on whether JMX messages or JMS messages and the AMQ JMS client are used.
Some management operations require a filter parameter to choose which messages are affected by the operation. Passing null or an empty string means that the management operation will be performed on all messages.
5.2. Managing AMQ Broker using JMX
You can use Java Management Extensions (JMX) to manage a broker. The management API is exposed by the broker using MBeans interfaces. The broker registers its resources with the domain org.apache.activemq.
For example, the ObjectName to manage a queue named exampleQueue is:
org.apache.activemq.artemis:broker="__BROKER_NAME__",component=addresses,address="exampleQueue",subcomponent=queues,routingtype="anycast",queue="exampleQueue"
The MBean is:
org.apache.activemq.artemis.api.management.QueueControl
The MBean’s ObjectName is built using the helper class org.apache.activemq.artemis.api.core.management.ObjectNameBuilder. You can also use jconsole to find the ObjectName of the MBeans you want to manage.
Managing the broker 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.
5.2.1. Configuring JMX management
By default, JMX is enabled to manage the broker. You can enable or disable JMX management by setting the jmx-management-enabled property in the broker.xml configuration file.
Procedure
-
Open the
<broker-instance-dir>/etc/broker.xmlconfiguration file. Set
<jmx-management-enabled>.<jmx-management-enabled>true</jmx-management-enabled>
If JMX is enabled, the broker can be managed locally using
jconsole.NoteRemote connections to JMX are not enabled by default for security reasons.
If you want to manage multiple brokers from the same
MBeanServer, configure the JMX domain for each of the brokers.By default, the broker uses the JMX domain
org.apache.activemq.artemis.<jmx-domain>my.org.apache.activemq</jmx-domain>
NoteIf you are using AMQ Broker on a Windows system, system properties must be set in
artemis, orartemis.cmd. A shell script is located under<install-dir>/bin.
Additional resources
- For more information on configuring the broker for remote management, see Oracle’s Java Management Guide.
5.2.2. MBeanServer configuration
When the broker runs in standalone mode, it uses the Java Virtual Machine’s Platform MBeanServer to register its MBeans. By default, Jolokia is also deployed to allow access to the MBean server using REST.
5.2.3. How JMX is exposed with Jolokia
By default, AMQ Broker ships with the Jolokia HTTP agent deployed as a web application. Jolokia is a remote JMX over HTTP bridge that exposes MBeans.
To use Jolokia, the user must belong to the role defined by the hawtio.role system property in the <broker-instance-dir>/etc/artemis.profile configuration file. By default, this role is amq.
Example 5.1. Using Jolokia to query the broker’s version
This example uses a Jolokia REST URL to find the version of a broker. The Origin flag should specify the domain name or DNS host name for the broker server. In addition, the value you specify for Origin must correspond to an entry for <allow-origin> in your Jolokia Cross-Origin Resource Sharing (CORS) specification.
$ curl http://admin:admin@localhost:8161/console/jolokia/read/org.apache.activemq.artemis:broker=\"0.0.0.0\"/Version -H "Origin: mydomain.com"
{"request":{"mbean":"org.apache.activemq.artemis:broker=\"0.0.0.0\"","attribute":"Version","type":"read"},"value":"2.4.0.amq-710002-redhat-1","timestamp":1527105236,"status":200}Additional resources
- For more information on using a JMX-HTTP bridge, see the Jolokia documentation.
- For more information on assigning a user to a role, see Adding Users.
- For more information on specifying Jolokia Cross-Origin Resource Sharing (CORS), see section 4.1.5 of Security.
5.2.4. Subscribing to JMX management notifications
If JMX is enabled in your environment, you can subscribe to management notifications.
Procedure
-
Subscribe to
ObjectName org.apache.activemq.artemis:broker="<broker-name>".
Additional resources
- For more information about management notifications, see Section 5.5, “Management notifications”.
5.3. Managing AMQ Broker using the JMS API
The Java Message Service (JMS) API allows you to create, send, receive, and read messages. You can use JMS and the AMQ JMS client to manage brokers.
5.3.1. Configuring broker management using JMS messages and the AMQ JMS Client
To use JMS to manage a broker, you must first configure the broker’s management address with the manage permission.
Procedure
-
Open the
<broker-instance-dir>/etc/broker.xmlconfiguration file. Add the
<management-address>element, and specify a management address.By default, the management address is
queue.activemq.management. You only need to specify a different address if you do not want to use the default.<management-address>my.management.address</management-address>
Provide the management address with the
manageuser permission type.This permission type enables the management address to receive and handle management messages.
<security-setting-match="queue.activemq.management"> <permission-type="manage" roles="admin"/> </security-setting>
5.3.2. Managing brokers using the JMS API and AMQ JMS Client
To invoke management operations using JMS messages, the AMQ JMS client must instantiate the special management queue.
Procedure
-
Create a
QueueRequestorto send messages to the management address and receive replies. -
Create a
Message. -
Use the helper class
org.apache.activemq.artemis.api.jms.management.JMSManagementHelperto fill the message with the management properties. -
Send the message using the
QueueRequestor. -
Use the helper class
org.apache.activemq.artemis.api.jms.management.JMSManagementHelperto retrieve the operation result from the management reply.
Example 5.2. Viewing the number of messages in a queue
This example shows how to use the JMS API to view the number of messages in the JMS queue exampleQueue:
Queue managementQueue = ActiveMQJMSClient.createQueue("activemq.management");
QueueSession session = ...
QueueRequestor requestor = new QueueRequestor(session, managementQueue);
connection.start();
Message message = session.createMessage();
JMSManagementHelper.putAttribute(message, "queue.exampleQueue", "messageCount");
Message reply = requestor.request(message);
int count = (Integer)JMSManagementHelper.getResult(reply);
System.out.println("There are " + count + " messages in exampleQueue");5.4. Management operations
Whether you are using JMX or JMS messages to manage AMQ Broker, you can use the same API management operations. Using the management API, you can manage brokers, addresses, and queues.
5.4.1. Broker management operations
You can use the management API to manage your brokers.
- Listing, creating, deploying, and destroying queues
A list of deployed queues can be retrieved using the
getQueueNames()method.Queues can be created or destroyed using the management operations
createQueue(),deployQueue(), ordestroyQueue()on theActiveMQServerControl(with theObjectNameorg.apache.activemq.artemis:broker="BROKER_NAME"or the resource nameserver).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 is resumed, it will begin delivering the queued messages, if any. - Listing and closing remote connections
Retrieve a client’s remote addresses by using
listRemoteAddresses(). It is also possible to close the connections associated with a remote address using thecloseConnectionsForAddress()method.Alternatively, list connection IDs using
listConnectionIDs()and list all the sessions for a given connection ID usinglistSessions().- Managing transactions
In case of a broker crash, when the broker restarts, some transactions might require manual intervention. Use the the following methods to help resolve issues you encounter.
List the transactions which are in the prepared states (the transactions are represented as opaque Base64 Strings) using the
listPreparedTransactions()method lists.Commit or rollback a given prepared transaction using
commitPreparedTransaction()orrollbackPreparedTransaction()to resolve heuristic transactions.List heuristically completed transactions using the
listHeuristicCommittedTransactions()andlistHeuristicRolledBackTransactionsmethods.- Enabling and resetting message counters
Enable and disable message counters using the
enableMessageCounters()ordisableMessageCounters()method.Reset message counters by using the
resetAllMessageCounters()andresetAllMessageCounterHistories()methods.- Retrieving broker configuration and attributes
-
The
ActiveMQServerControlexposes the broker’s configuration through all its attributes (for example,getVersion()method to retrieve the broker’s version, and so on). - Listing, creating, and destroying Core Bridge and diverts
List deployed Core Bridge and diverts using the
getBridgeNames()andgetDivertNames()methods respectively.Create or destroy using bridges and diverts using
createBridge()anddestroyBridge()orcreateDivert()anddestroyDivert()on theActiveMQServerControl(with theObjectNameorg.apache.activemq.artemis:broker="BROKER_NAME"or the resource nameserver).- Stopping the broker and forcing failover to occur with any currently attached clients
Use the
forceFailover()on theActiveMQServerControl(with theObjectNameorg.apache.activemq.artemis:broker="BROKER_NAME"or the resource nameserver)NoteBecause this method actually stops the broker, you will likely receive an error. The exact error depends on the management service you used to call the method.
5.4.2. Address management operations
You can use the management API to manage addresses.
Manage addresses using the AddressControl class with ObjectName org.apache.activemq.artemis:broker="<broker-name>", component=addresses,address="<address-name>" or the resource name address.<address-name>.
Modify roles and permissions for an address using the addRole() or removeRole() methods. You can list all the roles associated with the queue with the getRoles() method.
5.4.3. Queue management operations
You can use the management API to manage queues.
The core management API deals with queues. The QueueControl class defines the queue management operations (with the ObjectName,org.apache.activemq.artemis:broker="<broker-name>",component=addresses,address="<bound-address>",subcomponent=queues,routing-type="<routing-type>",queue="<queue-name>" or the resource name queue.<queue-name>).
Most of the management operations on queues take either a single message ID (for example, to remove a single message) or a filter (for example, to expire all messages with a given property).
- Expiring, sending to a dead letter address, and moving messages
Expire messages from a queue using the
expireMessages()method. If an expiry address is defined, messages are sent to this address, otherwise they are discarded. You can define the expiry address for an address or set of addresses (and hence the queues bound to those addresses) in theaddress-settingselement of thebroker.xmlconfiguration file. For an example, see the "Default message address settings" section in Understanding the default broker configuration.Send messages to a dead letter address using the
sendMessagesToDeadLetterAddress()method. This method returns the number of messages sent to the dead letter address. If a dead letter address is defined, messages are sent to this address, otherwise they are removed from the queue and discarded. You can define the dead letter address for an address or set of addresses (and hence the queues bound to those addresses) in theaddress-settingselement of thebroker.xmlconfiguration file. For an example, see the "Default message address settings" section in Understanding the default broker configuration.Move messages from one queue to another using the
moveMessages()method.- Listing and removing messages
List messages from a queue using the
listMessages()method. It will return an array ofMap, oneMapfor each message.Remove messages from a queue using the
removeMessages()method, which returns abooleanfor the single message ID variant or the number of removed messages for the filter variant. This 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 filter. - Changing 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 5.6, “Using message counters”). The message counters can also be reset for a single queue using theresetMessageCounter()method. - Retrieving the queue attributes
-
The
QueueControlexposes queue settings through its attributes (for example,getFilter()to retrieve the queue’s filter if it was created with one,isDurable()to know whether the queue is durable, and so on). - 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 is resumed, it will begin delivering the queued messages, if any.
5.4.4. Remote resource management operations
You can use the management API to start and stop a broker’s remote resources (acceptors, diverts, bridges, and so on) so that the broker can be taken offline for a given period of time without stopping completely.
- Acceptors
-
Start or stop an acceptor using the
start()or.stop()method on theAcceptorControlclass (with theObjectNameorg.apache.activemq.artemis:broker="<broker-name>",component=acceptors,name="<acceptor-name>"or the resource nameacceptor.<address-name>). Acceptor parameters can be retrieved using theAcceptorControlattributes. See Network Connections: Acceptors and Connectors for more information about Acceptors. - Diverts
-
Start or stop a divert using the
start()orstop()method on theDivertControlclass (with theObjectNameorg.apache.activemq.artemis:broker="<broker-name>",component=diverts,name="<divert-name>"or the resource namedivert.<divert-name>). Divert parameters can be retrieved using theDivertControlattributes. - Bridges
-
Start or stop a bridge using the
start()(resp.stop()) method on theBridgeControlclass (with theObjectNameorg.apache.activemq.artemis:broker="<broker-name>",component=bridge,name="<bridge-name>"or the resource namebridge.<bridge-name>). Bridge parameters can be retrieved using theBridgeControlattributes. - Broadcast groups
-
Start or stop a broadcast group using the
start()orstop()method on theBroadcastGroupControlclass (with theObjectNameorg.apache.activemq.artemis:broker="<broker-name>",component=broadcast-group,name="<broadcast-group-name>"or the resource namebroadcastgroup.<broadcast-group-name>). Broadcast group parameters can be retrieved using theBroadcastGroupControlattributes. See Broker discovery methods for more information. - Discovery groups
-
Start or stop a discovery group using the
start()orstop()method on theDiscoveryGroupControlclass (with theObjectNameorg.apache.activemq.artemis:broker="<broker-name>",component=discovery-group,name="<discovery-group-name>"or the resource namediscovery.<discovery-group-name>). Discovery groups parameters can be retrieved using theDiscoveryGroupControlattributes. See Broker discovery methods for more information. - Cluster connections
-
Start or stop a cluster connection using the
start()orstop()method on theClusterConnectionControlclass (with theObjectNameorg.apache.activemq.artemis:broker="<broker-name>",component=cluster-connection,name="<cluster-connection-name>"or the resource nameclusterconnection.<cluster-connection-name>). Cluster connection parameters can be retrieved using theClusterConnectionControlattributes. See Creating a broker cluster for more information.
5.5. Management notifications
Below is a list of all the different kinds of notifications as well as which headers are on the messages. Every notification has a _AMQ_NotifType (value noted in parentheses) and _AMQ_NotifTimestamp header. The time stamp is the unformatted result of a call to java.lang.System.currentTimeMillis().
| Notification type | Headers |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.6. Using message counters
You use message counters to obtain information about queues over time. This helps you to identify trends that would otherwise be difficult to see.
For example, you could use message counters to determine how a particular queue is being used over time. You could also attempt to obtain this information by using the management API to query the number of messages in the queue at regular intervals, but this would not show how the queue is actually being used. The number of messages in a queue can remain constant because no clients are sending or receiving messages on it, or because the number of messages sent to the queue is equal to the number of messages consumed from it. In both of these cases, the number of messages in the queue remains the same even though it is being used in very different ways.
5.6.1. Types of message counters
Message counters provide additional information about queues on a broker.
count- The total number of messages added to the queue since the broker was started.
countDelta- The number of messages added to the queue since the last message counter update.
lastAckTimestamp- The time stamp of the last time a message from the queue was acknowledged.
lastAddTimestamp- The time stamp of the last time a message was added to the queue.
messageCount- The current number of messages in the queue.
messageCountDelta-
The overall number of messages added/removed from the queue since the last message counter update. For example, if
messageCountDeltais-10, then 10 messages overall have been removed from the queue. udpateTimestamp- The time stamp of the last message counter update.
You can combine message counters to determine other meaningful data as well. For example, to know specifically how many messages were consumed from the queue since the last update, you would subtract the messageCountDelta from countDelta.
5.6.2. Enabling message counters
Message counters can have a small impact on the broker’s memory; therefore, they are disabled by default. To use message counters, you must first enable them.
Procedure
-
Open the
<broker-instance-dir>/etc/broker.xmlconfiguration file. Enable message counters.
<message-counter-enabled>true</message-counter-enabled>
Set the message counter history and sampling period.
<message-counter-max-day-history>7</message-counter-max-day-history> <message-counter-sample-period>60000</message-counter-sample-period>
message-counter-max-day-history- The number of days the broker should store queue metrics. The default is 10 days.
message-counter-sample-period- How often (in milliseconds) the broker should sample its queues to collect metrics. The default is 10000 milliseconds.
5.6.3. Retrieving message counters
You can use the management API to retrieve message counters.
Prerequisites
Message counters must be enabled on the broker.
For more information, see Section 5.6.2, “Enabling message counters”.
Procedure
Use the management API to retrieve message counters.
// Retrieve a connection to the broker'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", messageCounter.getMessageCount(), messageCounter.getMessageCountDelta());
Additional resources
- For more information about message counters, see Section 5.4.3, “Queue management operations”.
