casual-queue¶
casual-queue
is a simple and lightweight queue manager.
casual-queue
differs from other xa-resources in the form that casual-queue
is ‘known’ to casual
, hence casual
can, and does, take shortcuts regarding
transaction semantics. User code does not have to bind/link to casual-queue
as
a xa-resource, it works more like service calls
groups¶
casual-queue
groups queues into groups, both logically and physically.
This enables possibilities to have different storage for different groups (and
their queues).
group names can be anything as long as they’re unique within the domain
.
queuebase¶
casual-queue
stores the group in a queuebase file (a sqlite database file)
at the configured path. You can specify where the group will be stored, via
domain/queue/group/queuebase: /some/fast/disk/group-a.qb
.
Default queuebase file for a group is $CASUAL_DOMAIN_HOME/queue/<group-name>.qb
in-memory¶
groups can be configured to have a non persistance in memory storage, this
is done with the magical name :memory:
(this is how sqlite
works, so this is
more a consequence of the choice to use sqlite
as storage manager).
queues¶
Every queue gets a corresponding error-queue, which takes the name:
<queue-name>.error
queues can be named to anything as long as they’re unique within the domain
,
this includes the generated error queues. Hence, it’s not possible to create
foo
and foo.error
, since the latter will collide with the generated.
queues can be configured to have retry.count
and retry.delay
:
retry.count
: how many times a message can be dequeued and rolledback before the message is moved to the error queueretry.delay
: how long time should the message be not available after a dequeue and rollback.
error-queues can be accessed exactly like any other queue. The only
difference is that retry
will always be retry.count = 0
and
retry.delay = 0s
, or rather, the retry
will not be taken into account for
error-queues.
The only way to remove messages from an error-queue is to consume the messages (dequeue [successful commit]), if a rollback takes place the message will remain on the error-queue.