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?
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.