Why ActiveMQ, as opposed to a simple Queue/Mutex?

Question

Tomorrow I am presenting my rationale for choosing an in-process message queue implementation, and I'm unable to articulate my reasoning. My co-designers are proposing that we implement a simple asynchronous queue using just a basic list of jobs and a mutex to control access, where I'm suggesting ActiveMQ in embedded mode. I've personally been very impressed by ActiveMQ, and I would like to have some good, solid arguments to back up my gut impression.

If it matters, the application is basically 1 producer/n consumers, with priority and type information specific to the individual jobs being processed.

It's worth noting that so far the manageability and extensibility of the solution have not been powerful arguments. I'd love it if someone could give my arguments more punch. Can the forum help me out with that?

Answer 1

If manageability and extensibility are not high priorities then I have to wonder what your reasons are for wanting to use a manageable message queue? Maybe your colleagues are right, and you really don't need the extra feature set?

Answer 2

Not having to debug concurrency code in weird edge cases is a big benefit. I don't know how important this structure is as part of your overall project, but if the message queue is a big part of your project, then you can reap tremendous benefits by using an implementation that someone else has written, already debugged, and will maintain for you. If it's just some one-off part of an unimportant subsystem, it probably doesn't matter what you end up doing. But if it's critical, I'd much rather file a bug report than spend my time debugging concurrency code (I'm already starting to recoil in fear!).

The short version: Don't let NIH syndrome stop you from using someone else's work to get your job done faster, better, and cheaper. But don't build a mountain out of a molehill, either.

Answer 3

Your coworkers arguments are not without merit. Adding ActiveMQ to the project is adding yet another dependency. It will probably be more complicated to use, and it will have a greater footprint than a custom solution. Also, since you are adopting it, it is likely going to become your responsibility to maintain and keep working smoothly - bugs and all.

That said, ActiveMQ (and other queues) will do things that you could write yourself, but might prove to be a pain. Supporting the entire JMS API is one of them (though I am presuming you are using Java...if you are not, then this point is not valid). Serializing excess messages to disk in high memory situations is another. Durable subscribers and message selectors are a few other things that come to mind. Mostly bells-and-whistles sort of thing for your needs it seems, but they become very important for reliable message delivery.

Whatever you decide, encapsulate the final choice of message broker away from the client code to make it easier to switch.