Erlang's core architecture and OTP libraries provide strong support for distributed programming, including standard approaches to clustering and failover, which provide the foundation for RabbitMQ's existing clustering capabilities. These will be enhanced further in future broker releases.

Generalised overload protection and quality-of-service is an important area. Our implementation is structured in a way that will allow fine-grained control over quality-of-service parameters. In particular, we plan to support queue overload protection, producer/consumer flow control, and prefetch windowing.

Certain parts of the AMQP specification are not currently implemented (see the compatibility page for details). We plan on implementing missing features such as

• message priorities
• the basic.reject message
• clustering support messages
• the no_local parameter to basic.consume

Currently, AMQP is bound only to a binary TCP/IP-based transport protocol. In future, bindings for SCTP, HTTP, UDP etc. will appear. Our implementation is structured to make support for additional transports straightfoward.

We plan on providing a monitoring and management service, controllable by RPC over AMQP. This will allow developers and users to analyse the live state of the system and to create configurations which can be loaded into the system, creating particular setups of exchanges, queues, bindings, users, virtual hosts and realms.

We plan on providing a public, documented API for adding Erlang-native services to run within the Erlang cluster hosting the broker.

While our current performance is good, we will be taking care to improve our benchmark results.

We aim to provide integrated gateways to other systems, such as JMS, WS-RX, RTMP, XMPP, FIX and FAST.

We plan on implementing value added features not in the protocol document such as last-value cache, content-based routing, and optimised handling of structured data such as XML.

Currently, the broker implements only the AMQP PLAIN authentication mechanisms, in various forms for supporting the RabbitMQ Java client, the Qpid Java client, and the Qpid Python client. A future release will support other SASL mechanisms, in particular CRAM-MD5.

We plan on supporting encryption and message-authentication services for message streams carried via AMQP, as well as supporting AMQP-over-TLS as the standard is developed.

For smooth integration with existing networks, RabbitMQ will need to access shared configuration and user databases such as LDAP, Active Directory, and others.

Many applications require write-behind logging of messaging activity to a traditional RDBMS. We plan on exploring the different alternatives for providing such a service as part of RabbitMQ.

Currently, entities such as Queues, Exchanges and Tickets are represented in the Java Client API by simple strings or integers. For improved type-safety, the API will be extended to use an object-oriented representation of these entities.

Currently, the Java client implements only the AMQP PLAIN authentication mechanisms. A future release will support other SASL mechanisms, in particular CRAM-MD5. We also aim to develop support for AMQP-over-TLS.

The current client implementation does not fail over gracefully to any backup servers. We plan on keeping a record of entities required by a session and transactions in progress. When the client fails over to a backup server, it will recreate all required entities, and continue transparently.

We plan on developing a lightweight connector to the Mule Enterprise Service Bus. This will allow RabbitMQ to bridge to a vast array of legacy networking systems.

For smooth integration with existing systems, JavaEE's transaction model needs to be harmonized with AMQP's transaction model. Future work will investigate a mapping between the two.