0.6 Feature Descriptions

Incomplete

This page is a work-in-progress and should considered neither complete nor correct at this point.

Join In

I have started a thread about this table on the dev mailing list - "0.6 Feature Matrix". Let us know what you think!

1. Related Pages

0.6 Feature Matrix
0.6 Interoperability Matrix

2. Protocol Features

2.1. AMQP

Advanced Message Queuing Protocol (AMQP) is an Open Messaging Middleware standard upon which Qpid's wire protocol is based. The standard is maintained by the AMQP Working Group. Currently the following versions of the protocol exist:

0-8, released June 2006. This is the first working version of AMQP.
0-9, released December 2006. This version improves reliability aspects of the protocol.
0-9-1, released November 2008 (after 0-10).
0-10, released February 2008.
1-0, not yet released, is slated to be the first stable release of AMQP. Version 1-0 is currently in final draft (PR2).

2.2. Producer Flow Control

The broker will throttle (reduce) the rate at which clients can publish messages if the broker starts to run low on resources or if queue size policies dictate.

For a detailed discussion, see the following pages:

2.3. Transactions

Local one-phase commit (1PC) transactions ensure atomicity over a number of otherwise disconnected actions on the broker (such as publishing or consuming a number of messages in a group). For local transactions, the broker creates an internal transaction ID and uses it to track the state of the transaction. The client must either commit or abort the transaction to close it.

2.4. Distributed Transactions

Distributed two-phase commit (2PC) transactions ensure atomicity over a number of otherwise disconnected actions on a distributed system (which involve two or more brokers and/or clients). This operation is usually coordinated by an external transaction monitor which creates transaction IDs and controls the state of the transaction.

For a detailed discussion, see the following resources:
The AMQP Distributed Transaction Classes

2.5. SSL

SSL allows IP communications between the broker(s) and client(s) to be encrypted.

For a detailed discussion, see the following resources:
SSL
Configure Java Qpid to use a SSL connection.
JMX SSL Configuration
FAQ

2.6. RDMA

Remote Direct Memory Access (RDMA) permits high-throughput, low-latency communications between broker(s) and client(s). Among its features is zero-copy networking in which the network hardware copies networked data directly to the application memory space without the use of operating system buffers. RDMA implementations include Infiniband and iWarp (which uses RDMA over TCP).

3. Broker Features

3.1. Access Control Lists (ACL)

Security mechanism by which users may be granted permissions to perform the various operations on a broker from a client.

For a detailed discussion, see the following resources:
Qpid Design - Access Control Lists
Qpid ACLs
ACL (v2 ACL format specification, used on both Java and C++ brokers)
Java XML ACLs (deprecated: v1 XML-based ACL format specification used on M4 release Java broker)

3.2. Clustering

Module which allows several brokers to form an active-active or high availability (HA) cluster, primarily for reliability.

For a detailed discussion, see the following resources:
Starting a cluster
Persistent Cluster Restart Design Note
Old Clustering Design Note

3.3. Federation

Mechanism by which brokers can be connected primarily for the purpose of sharing load and providing broker-broker connectivity.

For a detailed discussion, see the following resources:
Using Broker Federation
Federation Design Note

3.4. QMF Management Exchange

QMF is a general-purpose management bus built using Qpid. Qpid itself may be managed using this facility. The Management Exchange is the component loaded by the broker to enable management functionality on a broker.

For a detailed discussion, see the following resources:
Qpid Management Framework
Qpid Management Features

3.5. QMF Agent

The QMF agent is the component which is embedded into the managed entities, and provides QMF awareness to that entity.

For a detailed discussion, see the following resource:
Qpid Management Framework

3.6. JMX Management Console

The Qpid JMX Management Console is a standalone Eclipse RCP application that communicates with the broker using JMX.

For a detailed discussion, see the following resources:
Qpid JMX Management Console
JConsole
Qpid JMX Management Console User Guide
Qpid JMX Management Console Testing Guide

3.7. QMan

QMan is a management bridge for Qpid. It exposes the broker's QMF management interfaces using Java Management Extensions (JMX) and / or OASIS Web Services Distributed Management (WSDM).

For a detailed discussion, see the following resource:
QMan - Qpid Management bridge

3.8. Replication

Asynchronous replication of queue state through the use of events on a secondary broker.

For a detailed discussion, see the following resource:
queue state replication

3.9. Watchdog

The watchdog plug-in will kill the qpidd broker process if it becomes stuck for longer than a configured interval.

3.10. XML Exchange

A plug-in exchange which can open messages and run xquery against it's XML content in order to determine routing to the appropriate queue.

3.11. Last Value Queue (LVQ)

A queue in which the content is maintained as key-value pairs. Publishing to a LVQ updates the value against its key; consuming a message for a particular key allows the last value to be read. The key/value pair may or may not be consumed, depending on options.

For a detailed discussion, see the following resources:
LVQ
LVQ Example

3.12. Priority Queue

Queues in which the delivery order is determined primarily by the priority of the message, and secondarily by the order of arrival.

For a detailed discussion, see the following resources:
Use Priority Queues
Qpid Design - Queue Implementation - see section on Priority Queues

3.13. SASL Security

Simple Authentication and Security Layer - an industry standard framework for authentication, and implemented in Qpid.

For a detailed discussion, see the following resources:
Qpid Design - Authentication
Qpid Interoperability Documentation - Authentication mechanism interoperability

3.14. BDB Store Module

An implementation of a persistence store using Oracle Berkeley Database (BDB) which provides persistence to exchanges and queues and their configurations, and to the messages on these queues. Exchanges, queues and messages must be set to be persistent before they will be persisted. In addition, only persistent queues may store persistent messages.

For a detailed discussion, see the following resource:
MessageStore Tool

3.15. SQL Database Store Module

An implementation of a persistence store using a QSL database which provides persistence to exchanges and queues and their configurations, and to the messages on these queues. Exchanges, queues and messages must be set to be persistent before they will be persisted. In addition, only persistent queues may store persistent messages.

3.16. Async Store Module

A Linux-only implementation of a persistence store using a combination of BDB (for exchange and queue configuration) and a custom-written asynchronous store (for message content and transactions). This store is capable of writing messages to disk at high rates through the use of DMA. Exchanges, queues and messages must be set to be persistent before they will be persisted. In addition, only persistent queues may store persistent messages.

3.17. Durable Exchanges

Exchanges and their configuration are persisted so that they do not need to be recreated on recovery or on startup of a previously running broker where they were present. The exchange must be set to be persistent and there must be a store module loaded for this persistence to be active.

3.18. Durable Queues

Queues and their configuration are persisted so that they do not need to be recreated on recovery or on startup of a previously running broker where they were present. The queue must be set to be persistent and there must be a store module loaded for this persistence to be active. Note also that only persistent queues can store persistent messages and recover them at recovery/startup.

3.19. Durable Bindings

Bindings and their configuration are persisted so that they do not need to be recreated on recovery or on startup of a previously running broker where they were present. The exchange and the queue being bound must be set to be persistent and there must be a store module loaded for this persistence to be active.

Child pages