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.

clear

To clear a queue, that is, remove and discard messages, use

$ casual queue --consume <some-queue> > /dev/null

configuration

example

 
domain:
  name: queue-centric-domain-example

  queue:
    default:
      queue:
        retry:
          # number of times a message can be rolled back before it will be moved to 
          # error queue
          count: 3 

          # duration until a rolled backed message is available for consumption (SI-units: h, min, s, ms, us, ns)
          delay: 20s


      directory: ${CASUAL_DOMAIN_HOME}/queue/groups

    groups:
      - name: groupA
        note: "will get default queuebase: ${CASUAL_DOMAIN_HOME}/queue/groupA.gb"
        queues:
          - name: q_A1

          - name: q_A2
            retry:
              count: 10
              delay: 100ms
            note: after 10 rollbacked dequeues, message is moved to q_A2.error

          - name: q_A3
          - name: q_A4

      - name: groupB
        queuebase: /some/fast/disk/queue/groupB.qb
        queues:
          - name: q_B1
          - name: q_B2
            retry:
              count: 20

            note: after 20 rollbacked dequeues, message is moved to q_B2.error. retry.delay is 'inherited' from default, if any

      - name: groupC
        queuebase: ":memory:"
        note: group is an in-memory queue, hence no persistence
        queues:
          - name: q_C1

          - name: q_C2

For a more accurate configuration example (generated example), see domain