I am investigating a new solution for a work queue. The queue, (or queues), will contain work items which will be worked by a human using a web based software system which consumes the items from the queue. Therefore, items on the work queue may remain on the queue for a long time. The queue solution will not need to handle large throughput, it won’t need to be a fast system but should act in the same way as a message queue. i.e. multiple consumers feeding off first in first out messages.
In addition to the work consumers I need to have the ability to manage the queue. View work items on the queue, edit them, remove them, change priority, etc…
I have investigated ActiveMQ, RabbitMQ, HornetQ and other JMS compliant queue solutions. These all seem to be fine, i.e. scalable, robust etc.. but lack a built in management capability to suit my requirements. They also seem to be built for high throughput.
The system I am looking to replace consists of a queue system implemented simply as a database schema. Work item consumers pick from a table rather than an in memory queue. With the exception of scalability I am unsure as to what benefit an in memory solution, such as ActiveMQ, has over the existing system.
My question is: Should I build my work queue system based on one of these solutions, ActiveMQ, Rabbit, Hornet.. etc.. or is there an open source work queue system which is specifically built for the work queue purposes rather than high throughput message queue work? Or, should I just stick with a database schema based solution.
Many thanks.
John
You should not use a queueuíng mechanism – I would go with an in memory item. Remember you dont want to remove things, you may keep them in the tables for auditing etc. – this is not classical messaaging, it is more workflow status tracking. This has pretty much zero to do with queueing.