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

[offby1 <cr...@planetct.com>]

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?
-- 
View this message in context: http://www.nabble.com/Why-ActiveMQ%2C-as-opposed-to-a-simple-Queue-Mutex--tp23085063p23085063.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.