Enterprise Integration Zone is brought to you in partnership with:

Len DiMaggio is a software QE engineer for JBoss at Red Hat. Len concentrates on open source Java middleware and is located in the USA. Len has been contributing to DZone since 2009. Len is a DZone MVB and is not an employee of DZone and has posted 19 posts at DZone. View Full User Profile

MessageAlerts in JBossESB 4.7

02.10.2010
| 9291 views |
  • submit to reddit

JBossESB 4.7 includes some great new features. In this post, I wanted to highlight a feature that can help you determine whether one of your Services or Actions are clogging things up.

The new feature feature is "MessageAlerts" (org.jboss.soa.esb.listeners.message.MessageAlerts). This feature enables you to collect fine grained information on the processing time or number of bytes that a specific service, or a specific action in a service requires to process a single message.

You use MessageAlerts by defining processing time and byte total thresholds on a per service and/or action basis. When the service or action in question takes longer than the defined time threshold to process a message, a WARNING is written to the server log and made available in the JMX console. You define the thresholds with these properties:

alertTimeThreshold="420"
alertLengthThreshold="10"

The time-related threshold is measured in milliseconds. The length-related threshold is measured in bytes.

When would you use the byte total threshold? This can be useful if, for example, the service or action that you are watching performs transformations, and suddenly begins processing way more bytes than you're expecting that it should.

An Example in a Quickstart

The MessageAlerts feature is demonstrated in a quickstart named, appropriately enough, "messagealert." If you've ever run the "helloworld" quickstart, then this quickstart should be familiar. The only changes are the addition of the org.jboss.soa.esb.samples.quickstart.messagealerts.DelayAction action class (as you can guess by the name, this class introduces a delay to cause the alertTimeThreshold to be reached, and the changes in the jboss-esb.xml file listed below:

   <services>
<service
category="FirstServiceESB"
name="SimpleListener"
description="Hello World"
alertTimeThreshold="420"
alertLengthThreshold="10"
>
<listeners>
<jms-listener name="JMS-Gateway"
busidref="quickstartGwChannel"
is-gateway="true"
/>
<jms-listener name="helloWorld"
busidref="quickstartEsbChannel"
/>
</listeners>
<actions mep="OneWay">
<action name="action1"
class="org.jboss.soa.esb.samples.quickstart.messagealerts.MyJMSListenerAction"
process="displayMessage"
/>
<action name="action2" class="org.jboss.soa.esb.actions.SystemPrintln">
<property name="printfull" value="false"/>
</action>
<action name="action3"
class="org.jboss.soa.esb.samples.quickstart.messagealerts.DelayAction"
process="delayMessage"
alertTimeThreshold="30"
alertLengthThreshold="50">
</action>
</actions>
</service>
</services>


The changes related to MessageAlerts are:
  • Lines 6-7: These set the service thresholds at 420 milliseconds in time and 10 bytes in length.
  • Lines 29-30: And, these set the action thresholds at 30 milliseconds in time and 50 bytes in length.
When we deploy and run the quickstart, the following is written to the server.log:

 22:00:28,833 INFO [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
22:00:28,837 INFO [STDOUT] Body: Message Alerts
22:00:28,837 INFO [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
22:00:28,850 INFO [STDOUT] Message structure:
22:00:28,850 INFO [STDOUT] [Message Alerts].
22:00:31,852 WARN [ServiceMessageCounter] jboss.esb:category=MessageCounter,deployment=Quickstart_messagealerts.esb,service-category=FirstServiceESB,service-name=SimpleListener service, action3 action alert time 3001 took longer than 30 ms
22:00:31,853 WARN [ServiceMessageCounter] jboss.esb:category=MessageCounter,deployment=Quickstart_messagealerts.esb,service-category=FirstServiceESB,service-name=SimpleListener service, action3 action message size 2960 was larger than 50 bytes
22:00:31,853 WARN [ServiceMessageCounter] jboss.esb:category=MessageCounter,deployment=Quickstart_messagealerts.esb,service-category=FirstServiceESB,service-name=SimpleListener service alert time 3007 took longer than 420 ms
22:00:31,854 WARN [ServiceMessageCounter] jboss.esb:category=MessageCounter,deployment=Quickstart_messagealerts.esb,service-category=FirstServiceESB,service-name=SimpleListener service message size 2960 was larger than 10 bytes


And, the same information is available in the JMX log under jboss.esb, service=MessageAlerts:


As you can see in this screenshot, you can reset the counters through the JMX console. (And, yes, as you can also see in this screenshot, I'm staying up way too late at night writing about this stuff.)

You can also access the same information from the jboss.esb mbean directly:
sh ./twiddle.sh get "jboss.esb:service=MessageAlerts"

And, for extra credit, you can access the MessageAlerts service programatically. To do this, first, we'll modify the quickstart's jboss-esb.xml file to move the action that prints information to the server log to happen after the delay (and therefore after the MessageAlerts have been generated).

Then, we'll replace the code in MyJMSListenerAction.java with this:

   package org.jboss.soa.esb.samples.quickstart.messagealerts;  

import org.jboss.soa.esb.actions.AbstractActionLifecycle;
import org.jboss.soa.esb.helpers.ConfigTree;
import org.jboss.soa.esb.message.Message;

import javax.management.ObjectName;
import javax.management.MBeanServer;
import javax.management.MalformedObjectNameException;

import org.jboss.mx.util.MBeanProxyExt;
import org.jboss.mx.util.MBeanServerLocator;
import org.jboss.soa.esb.actions.AbstractActionPipelineProcessor;
import org.jboss.soa.esb.actions.ActionProcessingException;

import java.util.Vector;

public class MyJMSListenerAction extends AbstractActionLifecycle
{

protected ConfigTree _config;

public MyJMSListenerAction(ConfigTree config) { _config = config; }

public Message displayMessage(Message message) throws Exception{

MBeanServer server = org.jboss.mx.util.MBeanServerLocator.locateJBoss();
Vector theAlertsVector = (Vector)server.getAttribute(new ObjectName("jboss.esb:service=MessageAlerts"), "Alerts");

for (int i = 0; i < theAlertsVector.size(); i++ ) {
System.out.println("******Data returned from MessageAlert[" + i + "] = " + theAlertsVector.elementAt(i) + "\n" );
}

System.out.println("&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&");
System.out.println("Body: " + message.getBody().get()) ;
System.out.println("&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&");
return message;
}

}


  • Line 27: Locates the MBeanServer - this is easy as we are running in the same JVM as the server
  • Line 28: Retrieves the Vector of MessageAlerts from the jboss.esb MessageAlerts service
  • Lines 30-33: and prints them out

Closing Thoughts

The ability to building your own services and custom actions with JBossESB is one characteristic of its overall flexibility. With MessageAlerts, you can more easily track the efficiency of those services and actions, at a fine grained level. The message alert feature makes it simple.

Acknowledgements

Thanks to Tom Cunningham for his input to this post and his patient responses to my many questions!
References
Published at DZone with permission of Len DiMaggio, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)