High Quality JMS Messaging.

Introduction

The Queue Manager Swiftlet manages all queues of a SwiftMQ router. Queues are the base of point-to-point as well as publish/subscribe messaging. Concerning publish/subscribe, each subscriber is backed by a temporary queue and a durable subscriber by a regular queue.

A queue is a very light weighted object from the perspective of the queue itself (not from the content, of course). A SwiftMQ router can handle thousands of it. For each non-temporary queue, a persistent and a swap store is attached from the Store Swiftlet during the queue creation (a temporary queue has only a swap store attached). These stores are only used if needed. They don't consume resources such as disk space. A queue has a message cache where messages are stored for faster read access. If the cache is full, the messages are swapped to the swap store in the case that they are non-persistent. Persistent messages are always stored in the persistent store.

Access to a queue is handled in a first-in-first-out message order. The order is guaranteed within the same message priority. Messages are read and written covered by queue transactions. There is no way to access messages outside of queue transactions, so the access is always consistent. A queue is also capable to drive transactional access via the 2-Phase-Commit-Protocol. In that case, a prepare phase is added before a commit/rollback. 2PC transactions are managed by the transaction manager of the JMS XA/ASF Swiftlet as well as the XA Resource Manager Swiftlet to recover so-called in-doubt transactions (open prepared transactions).