You create a metrics monitoring client in the same way that you would write any JMS client, except that the client must subscribe to one or more special metrics message topic and must be ready to receive and process messages of a specific type and format.
No hierarchical naming scheme is implied in the metrics-message names. You can’t use a wildcard character (*) to identify multiple destination names.
Create a TopicConnectionFactory object.
Create a TopicConnection to the Message Queue service.
Create a TopicSession.
Create a metrics Topic destination object.
Create a TopicSubscriber.
Register as an asynchronous listener to the topic, or invoke the synchronous receive() method to wait for incoming metrics messages.
Process metrics messages that are received.
In general, you would use JNDI lookups of administered objects to make your client code provider-independent. However, the metrics-message production is specific to Message Queue, there is no compelling reason to use JNDI lookups. You can simply instantiate these administered objects directly in your client code. This is especially true for a metrics destination for which an administrator would not normally create an administered object.
Notice that the code examples in this chapter instantiate all the relevant administered objects directly.
You can use the following code to extract the type ( String) or timestamp (long) properties in the message header from the message:
MapMessage mapMsg; /* * mapMsg is the metrics message received */ String type = mapMsg.getStringProperty("type"); long timestamp = mapMsg.getLongProperty("timestamp");
You use the appropriate get method in the class javax.jms.MapMessage to extract the name-value pairs. The get method you use depends on the value type. Three examples follow:
long value1 = mapMsg.getLong("numMsgsIn"); long value2 = mapMsg.getLong("numMsgsOut"); int value3 = mapMsg.getInt("diskUtilizationRatio");