[Bernstein09] Section 4.5. The Queue Manager

4.5. The Queue Manager
that stores and manages queues. A queue manager is a lot like adatabase system. It supports the storage abstraction of a queue store.The queue store can be a conventional relational database system or acustom storage system designed specifically for queue management.Within a queue store, the queue manager supports operations to createand destroy queues and modify a queue’s attributes (e.g., owner,maximum size, queue name, user privileges). Most importantly, itsupports operations on messages in queues.
Operations on Queued Messages
Themain operations on messages are enqueue and dequeue. The queue managershould also support operations to examine a queue, such as to determineif it’s empty, and to scan a queue’s messages one by one without dequeuingthem. It might also support random access to messages in a queue; forexample, to read or dequeue the third message in the queue or a messagewith a specific ID.
Usually,the dequeue operation offers two options in dealing with an emptyqueue. If called with the nonblocking option, it returns with anexception that says the queue is empty. For example, this is useful ifa server is polling several queues and does not want to be blocked onan empty queue since another one may be nonempty. If called with theblocking option, the dequeue operation remains blocked until a messagecan be returned. The latter is useful, for example, to dequeue a replywhen it arrives.
Generalized Messaging
Wehave focused on using queued messages for the reliable processing ofrequests and replies. However, queuing can be used for other kinds ofmessages too. That is, the enqueue and dequeue operations can be usedto send and receive arbitrary messages. This is a peer-to-peermessaging scenario, where the communicating parties can exchangemessages in a general application-defined pattern, not just matchedrequest-reply pairs.
Inthis scenario, it is sometimes useful to use volatile queues. That is,the content of the queues do not survive system failures. Volatilequeues still offer many of the benefits discussed inSection 4.1, such as load balancing, priority scheduling, and the ability to communicate with an unavailable server.
Timeouts
Ifa message remains in a queue for too long without being processed, itmay need special attention. It is therefore useful to be able to attacha timeout to a message. If the timeout expires before the message hasbeen dequeued, then a timeout action is invoked, such as discarding themessage or enqueuing the message on another queue (e.g., an errorqueue) with a tag that explains the timeout.
Handling Poisoned Messages
Supposea message has faulty content that causes an abort of the transactionthat dequeues it. The abort will cause the dequeued message to bereturned to the queue. To avoid repeating this problem forever, a queuemay have a user-configurable threshold of the maximum number of times amessage can be dequeued. To avoid rejecting a message due to atransient system problem, the queue may offer control over the minimumtime between the retries. If the retry threshold is exceeded, themessage is moved to an error queue for manual reconciliation. This maybe done by the application, queue manager, or dispatcher, depending onthe implementation.
Message Ordering
Themessage in a queue may be ordered in a variety of ways, such asfirst-come, first-served, in which case an enqueue operation places thenew message at the end of the queue, or highest-priority-first, inwhich case an enqueue operation places the new message before the firstmessage in the queue of lower priority.
Whateverthe priority mechanism, the ordering is normally made fuzzy by thepossible abort of a transaction that does a dequeue. For example,suppose transaction T1 dequeues the first message M1 from the queue and then T2 dequeues the next message M2 (seeFigure 4.8). If T1 aborts, then its dequeue operation is undone, so M1 is returned to the queue. However, T2 might commit, in which case M2 ends up being processed before M1, even though it should have been processed after M1.
Figure 4.8. An Abort Destroys Priority Ordering. Although M1 is dequeued before M2, since T1 aborts, M2 is processed before M1.

To avoid this anomaly, T2 should not be allowed to dequeue M2 until after T1commits. For example, the queue may be set to disallow concurrentdequeues. Unfortunately, this eliminates concurrency among transactionsthat dequeue from the same queue, in this case T1 and T2,and therefore degrades performance. Since this reduction in concurrencyis only to prevent the relatively infrequent out-of-order dequeuingthat results from an abort, most systems allow concurrent dequeueoperations and ignore the occasional out-of-order dequeuing.However, in some applications, out-of-order processing is unacceptable,for example, for legal reasons. For example, in a stock trading system,orders submitted at the same price (to buy or sell) may be legallyrequired to be processed in strict arrival order. To obey this rule andget satisfactory concurrency, trading systems exploit the specificsemantics of the trading transactions themselves, for example, bybatching up a set of trades and committing them as a group (even thoughthey were submitted separately).
Filter Criteria
Somequeue managers offer clients the ability to dequeue messages based ontheir content. That is, rather than simply dequeuing the oldestmessage, the client can dequeue the oldest message that has aparticular value in one of its content fields. For example, the clientmight first dequeue a message with a field “importance” equal to thevalue “high.” If there are no such messages, then it could revert todequeuing the oldest one.
Nontransactional Queuing
Mostclients of the queue manager execute queue operations within atransaction. However, it is sometimes desirable to execute operationsas independent transactions, so the result is recorded whether or notthe surrounding transaction aborts. A classic example is a securityviolation. Suppose a running transaction discovers that the request itis executing is illegal—for example, it includes an illegal password.It is often important to record such violations, so they can beanalyzed later to find patterns of security break-in attempts. Thetransaction can do this by enqueuing a security violation message on aspecial queue. Even if the transaction aborts, the security violationshould still be persistently recorded. Therefore, the operation toenqueue the security violation message should run as a separatetransaction, which commits even if the transaction that called itaborts.
Journaling
Queuedmessages can provide a history of all the transactions that wereexecuted by a TP system. Therefore, some queue managers offer an optionto save a description of all operations on messages in a journal. Thejournal may be useful for finding lost messages or for auditingpurposes; for example, to prove that certain messages were submittedand/or processed, or to comply with government regulations, such as theSarbanes-Oxley Act.
Queue Management
Aqueue manager usually supports operations to start and stop a queue.Stopping a queue disables enqueue and dequeue operations. While thequeue is stopped, these operations return an exception. This is a wayof taking a queue off-line, for example, if the server that processesits messages is down. It is also useful to enable and disableenqueue and dequeue operations independently. For example, if a queueis full, enqueue operations can be disabled so the queue will notaccept any new work.
Routing
Aqueue manager usually supports flexible routing. For example, it maysupport queue forwarding, to move messages from one queue to another.This is useful to reroute a client system’s input queue to anotherserver system when the server is overloaded or down. It can also beused to save communications by batching up requests on one system andsending them later in bulk to another system, rather than sending themone by one. Queue forwarding involves reading one or more messages fromone queue, moving them to the other queue, storing them on disk, andthen committing, thereby removing the messages from one queue andinstalling them on the other queue as one transaction.
A typical configuration that exploits queue forwarding is shown inFigure 4.9.The client can reliably enqueue requests locally, whether or not theserver system is available. Requests on the local queue cansubsequently be forwarded to the server’s queue. The queue managermight offer an option to send an acknowledgment to the client when themessage reaches its final destination, in this case on System B, orwhen the transaction that dequeues the message has committed.
Figure 4.9. Forwarding with Local Enqueuing. Theclient enqueues requests to its local queue. Those requests aretransparently forwarded to the server’s queue, where the serverdequeues them locally.

Thetransaction to forward a request adds a fourth transaction to thethree-transaction model and a fifth if a reply is needed.Alternatively, a client could enqueue its requests directly to a serverqueue, without using a local queue as an intermediary. This saves thefourth transaction to forward the request and a fifth to return areply. However, the client is unable to submit transactions when theremote queue is unavailable. Some products offer both queue forwardingand remote queuing. This allows a hybrid scheme, where the clientenqueues to the remote server queue when it’s available, otherwise ituses a local queue.
Ofcourse, for a client to support a local queue, it needs a queue store.This requires additional hardware resources and systemadministration—the price to be paid for the additional availability.
A queue manager may also support parameter-based routing, as was described inSection 2.6.This allows a queue to be partitioned onto multiple systems forscale-out. It may also enable more flexible reconfiguration options.For example, if a queue is overloaded, messages with certain parametervalues can be directed to a more lightly loaded queue simply bychanging the mapping of parameter values to queue names.
Dispatcher
A queue manager usually includes a dispatcher, to support a push model as mentioned near the end ofSection 4.2.Instead of requiring an application to call the queue manager todequeue a message, the dispatcher calls the application when a newmessage appears on the queue. Many scheduling options are possible: Itmay do this (1) every time a new message arrives, (2) only if a newmessage arrives when the application is not currently running, (3) whenthe queue reaches a certain length, or (4) at fixed time intervalsprovided the queue is nonempty. The dispatcher may also include loadcontrol, to limit the number of application threads it can invoke. Thatis, if the maximum number of application threads are already executing,then a new message that appears on the queue must wait there until athread finishes executing its current request.