ActiveMQ 5.1.0

At Mailtrust, they tend to use ActiveMQ as their Universal Messaging System (UMS). That was the first time for me to start reading about messaging systems and the distributed handling of messages. This post is not about comparing ActiveMQ to other distributed messaging systems. However, ActiveMQ is an open source message broker that is written in Java; It supports communication over a number of protocols such as Stomp and OpenWire; and it is pretty cool :) .

In this post, I am not going to dig into the details of their implementation. However, I’d like to mention that there is a good opportunity for freelance developers to enhance ActiveMQ by implementing a number of features.

Here is a scenario that highlights one of the most important concerns about ActiveMQ. A producer P1 sends a number of messages to two brokers (B1 and B2). There are two consumers on these two brokers respectively (C1 and C2). Ideally, if the producer sends 50 messages, then each consumer should receive 25 messages. With the right configurations and the approperiate dispatching algorithm, you can do this with the current version of ActiveMQ. If C2 processed only 10 of the 25, then there would be 15 messages pending in the queue. However, if C2 died after processing the 10th message, the pending 15 messages would remain at B2 and they won’t be forwarded to B1.

There are different ways of implementing this feature into the current source code of ActiveMQ. Aside from the details of how the code works, I am more interested in how we can separate our implementation from the source code of ActiveMQ. In other words, I don’t want our implementation to be affected by releasing a new version of ActiveMQ. In fact, I want our implementation to be pluggable to any version of ActiveMQ.

This is a typical separation of concerns problem. The good news is that there are several ways to do that. The bad news is that every method has its own pros and cons. For now, we think that we might want to use AspectJ as well as DRIVEL to embed our code into ActiveMQ.

Share your thoughts.

posted: 08 July 16
under: ActiveMQ, Open Source

3 Responses to “ActiveMQ 5.1.0”

  1. Bruce Snyder says:

    Have you considered just implementing rules for routing using Apache Camel?

  2. Apache Camel is certainly an option to look at. My only concern about Apache Camel Spring Framework is that it is only triggered when messages arrive at the queue, but not after they become pending messages waiting for a consumer to consume them. Maybe this behavior is different when writing routing rules using Java.

    Thanks for the thought.

  3. Firstly I’d say, whatever your requirements are – discuss them with the open source project before you start hacking away as it might well be that there’s a way of implementing what you need – easily – that will work with any release and avoid you maintaining your own local patches.

    Secondly – what you describe is pretty much a simple Store & Forward Network of Brokers. Why not just use that?

    http://activemq.apache.org/networks-of-brokers.html

Leave a Reply

Get Adobe Flash playerPlugin by wpburn.com wordpress themes