In pre-v6, action queues are quite hard to understand, because the syntax is very counter-intuitive. Based on a recent conversation, I thought I share a little bit of advise on how queues work.
Each action has a dedicated queue. This queue can be in-memory, it can be on disk and it can be a combination of both. There is also direct mode, which means by design there is a queue but the actual driver does forward messages to the action without action queueing.
When you define actions, the queue parameters belong to the next action (in v6 this is far easier to understand and see as the queue params are specified within the action). In the snippet below, we have two actions, and each of them is configured with different queue settings. This results with two different sets of queue files being written. It is important that the queue file names are different (as they are), but otherwise the queues are independent. There can be as many disk (or DA) queues as there are actions. Note that if there is only a single action queue and n actions, this means only one action uses the disk queue, whereas n-1 actions do not use it (if nothing else is set, they run in direct mode).
$ActionQueueType LinkedList # use asynchronous processing
$ActionQueueFileName nfsq # set file name, also enables disk mode
*.* /var/log/log1
$ActionQueueType LinkedList # use asynchronous processing
$ActionQueueFileName diskq # set file name, also enables disk mode
*.* /var/log/log2
*.* /var/log/log3 # DIRECT mode here!!!!
In v6, queue parameters are set directly within the action:
*.* action(type="omfile"
queue.filename="nfsq" queue.type="linkedlist"
file="/var/log/log1")
*.* action(type="omfile"
queue.filename="diskq" queue.type="linkedlist"
file="/var/log/log2")
*.* action(type="omfile" file="/var/log/log3")
The v6 format hopefully make more clear what belongs together.