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 queue

  • retry.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.

configuration

see configuration.domain.queue.operation