Why AllQueue?

There are many queeing platforms available that all have their own strengths and weaknesses.

For many their weakness is complexity and maintenance. RabbitMQ, Apache ActiveMQ, HornetQ, and NATS to name a few. While these are industry tested, deploying, maintaining and updating them are no small task. Additionally, when something goes wrong with a single component, it is often difficult to deduce the underlying problems.

For some, their weakness is a lack of functionality. For example, AWS SQS doesn't have any sense of prioritization. Some queue don't have a sense of "fail after X attempts". Few queues have built in throttling for individual queues. Even fewer have a sense of 'workflows', where one job waits until another one (or many) are completed before running. AllQueue is an attempt to meet all these needs.

Here is a list of features that AllQueue has:

• Simple deployment/configuration

• Delayed Jobs

• Independent named queues

• Prioritization within a queue (no need for different queues for 'priorty' jobs)

• Dead Letter queue

• Synchronous workflows (Jobs that depend on other jobs completing)

• Throttling queues

• In memory/disk based persistance

• Federated sharding for scalability

• Does not require ongoing maintenance of internal storage or sub-applications

• Speed

Limitations:

• Docker ONLY install, on both client and server

• Not designed for long life jobs

• Work queue, NOT a pub/sub queue, pull only