queuey 0.8

RESTful Message Queue

Read the full documentation at http://queuey.readthedocs.org/

Wat? Another message queue?

Given the proliferation of message queue's, one could be inclined to believe that inventing more is not the answer. Using an existing solution was attempted multiple times with most every existing message queue product.

The others failed (for our use-cases).

Queuey is meant to handle some unique conditions that most other message queue solutions either don't handle, or handle very poorly. Many of them for example are written for queues or pub/sub situations that don't require possibly longer term (multiple days) storage of not just many messages but huge quantities of queues.

Queuey Assumptions and Features:

• Messages may persist for upwards of 3 days
• Range scans with timestamps to rewind and re-read messages in a queue
• Millions of queues may be created
• Message delivery characteristics need to be tweakable based on the specific cost-benefit for a Queuey deployment
• HTTP API for easy access by a variety of clients, including AJAX
• Authentication system to support multiple 'Application' access to Queuey with optional Browser-ID client authentication
• A single deployment may support multiple Applications with varying message delivery characteristics, and authentication restricted queue access

Queuey can be configured with varying message guarantees, such as:

• Deliver once, and exactly once
• Deliver at least once (and under rare conditions, maybe more)
• Deliver no more than once (and under rare conditions, possibly not deliver)

Changing the storage back-end and deployment strategies directly affects the message guarantee's. This enables the Queuey deployment to meet different requirements and performance thresholds.

For more background on Queuey, see the Mozilla wiki section on queuey.

$ make

make cassandra

./bin/cassandra/bin/cassandra -p cassandra.pid

kill -2 `cat cassandra.pid`

bin/pserve etc/queuey.ini