Friday, March 27, 2009

Live from Apache Con in Amsterdam

I am writing this entry as I am sitting at Apache Con in Amsterdam. It is a really good conference with good and plenty information around evrything that is currently going on in the Apache community. In the middle of the conference Ade and I had 6 sessions in total where we discussed the activities of the FUSE team in the Apache community, especially focussing on the FUSE ESB (Apache ServiceMix), the FUSE Message Broker(Apache ActiveMQ) and the FUSE Services Framework (Apache CXF).

It was surprising to me the it was relatively unknown in the community that the FUSE of PROGRESS employs so many active committers and the conference was a god place to explain what we are doing. I have made my presentations available at the ApacheCon web site and we will put them on the FUSE web site as well.

Enjoy reading...

Better Diagnosis for ActiveMQ

Over the last couple of weeks I was involved in a number of projects where we had to understand how messages are being handled within an ActiveMQ broker. Browsing the ActiveMQ code I found the LoggingBrokerPlugin that did some rudimentary logging upon message sends.

That seemed to be a good point to have a little enhancement to ActiveMQ itself. ActiveMQ basically provides a framework for writing plugins that can hook into the message processing within the broker. Usually such a plugin extends the BrokerFilter class.

As there is a whole lot of events it made sense to categorize the events into certain classes to prevent the log files being flooded with unnecessary information. I have finally contributed a patch to ActiveMQ that provides this kind of functionality.

In a nutshell, the plugin can be attached to the broker via the normal ActiveMQ XML configuration :

<broker usejmx="true" deleteallmessagesonstartup="true" xmlns="">
<transportconnector uri="tcp://localhost:61616" />
<loggingbrokerplugin logconnectionevents="true" />

With the configuration above and a logger assigned to in the log4j settings you will
see log entries whenever a JMS client connects to or disconnects from the broker and when a session is created/closed by these clients. Other
event classes include transaction events, consumer events and producer events. The internal event group is some kind of a catch all group
that produces log entries for methods that are only of interest for debugging.

As a side note, the methods in the plugin also provide excellent entry points for debugging in to the broker behavior.