[rabbitmq-discuss] RabbitMQ 1.8.0 release

Matthew Sackman matthew at rabbitmq.com
Wed Jun 16 16:10:12 BST 2010

The RabbitMQ team is pleased to announce the release of RabbitMQ 1.8.0.

This release introduces several APIs to extend Rabbit in a pluggable
way, first with pluggable exchange types, and then with pluggable
backing queues. Other improvements include optimisations for cross-node
routing within a cluster, and more rigorous enforcement of channel.flow
to ensure that Rabbit can stop producers who are failing to obey the
instruction to stop sending messages to Rabbit when Rabbit comes under
memory pressure.

There are many semantic changes to bring the behaviour of Rabbit closer
towards the AMQP 0-9-1 specification. These are covered in detail in the
release notes below.

Please note this release of the RabbitMQ broker requires at least Erlang
version R12B-3.

This release does *not* contain the new persister, which is making good
progress through QA and will appear in a future release.

Finally, due to an issue we're currently seeing with the nexus/sonatype
maven repository, the 1.8.0 release is not yet available in maven. We
will rectify this as soon as we can.

For details see the attached release notes.

Binary and source distributions of the new release can be found in the
usual place, at http://www.rabbitmq.com/download.html

We recommend that all users of earlier versions of RabbitMQ upgrade to
this latest release.

As always, we welcome any questions, bug reports, and other feedback
on this release, as well as general suggestions for features and
enhancements in future releases. Mail us via the RabbitMQ discussion
list at rabbitmq-discuss at lists.rabbitmq.com, or directly at
info at rabbitmq.com.


The RabbitMQ Team

Release: RabbitMQ 1.8.0

Release Highlights

bug fixes
- prevent a change in host name from preventing RabbitMQ from being
- ensure that durable exclusive queues do not survive a restart of the
- fix a race condition that could occur when concurrently declaring
  exclusive queues.
- ensure that queues being recovered by a node in a cluster cannot be
  accessed via other nodes until the queue is fully initialised.
- prevent bursts of declarations or deletions of queues or exchanges
  from exhausting mnesia's transactional capacity.
- prevent bursts of connections from exhausting TCP backlog buffers.
- various corrections to documentation to correct discrepancies
  between the website, the man pages, and the commands' usage outputs.

- introduce a pluggable exchange type API permitting plugins to the
  broker to define new exchange types which can then be used by
- introduce a backing queue API permitting plugins to the broker to
  define new ways in which messages can be stored.
- several semantic changes to bring the behaviour inline with the AMQP
  0-9-1 spec:
  + honour many of the queue exclusivity requirements for AMQP 0-9-1,
    such as queue redeclaration, basic.get, queue.bind and
  + honour exchange and queue equivalence requirements for AMQP 0-9-1,
    especially for queue and exchange redeclaration.
  + ensure that exclusive queues are synchronously deleted before the
    connection fully closes.
  + permit durable queues to be bound to transient exchanges.
  + enforce detection and raising exceptions due to invalid and reused
    delivery-tags in basic.ack rigorously
  + queue.purge now does not remove unacknowledged messages.
- require clients to respond to channel.flow messages within 10
  seconds to avoid an exception being raised and more rigorously deal
  with clients that disobey channel.flow messages. See
- the server now supports the client sending channel.flow messages to
  temporarily halt the flow of deliveries to the client.
- optimise cross-node routing of messages in a cluster scenario whilst
  maintaining visibility guarantees.
- ensure that clients who present invalid credentials cannot flood the
  broker with requests.
- drop support for versions of Erlang older than R12B-3.
- ensure that the minimum number of frames are used to deliver
  messages, regardless of incoming and outgoing frame sizes.
- display the current version of Erlang when booting Rabbit, and
  ensure the version is sufficiently youthful.
- work around some name resolver issues, especially under Windows.
- introduce a Pacemaker OCF script (and then fix it, thanks to patches
  by Florian Haas) to permit RabbitMQ to be used in basic
  active/passive HA scenarios (see

java client
bug fixes
- fix a race condition when closing channels which could lead to the
  same channel being closed twice.
- MulticastMain could calculate negative rates, due to integer
- be consistent about naming conventions.

- Java client is now available via Maven Central.
- redesign the ConnectionFactory to be more idiomatic.
- expose server properties in connection.start.
- allow additional client properties to be set in connection.start_ok.
- attempt to infer authentication failures and construct appropriate
- MulticastMain now logs returned publishes.

.net client
bug fixes
- prevent memory leak due to DomainUnload event handler.
- improvements to catching connections which are timing out.
- ensure explicitly numbered closed channels return their channel
  number to the pool correctly.
- removed artificial limitation on maximum incoming message size.

- expose server properties in connection.start.
- allow additional client properties to be set in connection.start_ok.
- attempt to infer authentication failures and construct appropriate

code generation
- permit multiple specifications to easily be combined and merged.
- permit any number of different "actions" in code generation.

building & packaging
bug fixes
- stop the INSTALL file from being installed in the wrong place by the
  Debian packages.

- source rpm (.src.rpm) packages are now available
- rpm packages are now noarch, matching the debs

The database schema and the format in which persistent messages are
stored have both changed since the last release (1.7.2). When
starting, the RabbitMQ server will detect the existence of an old
database and will move it to a backup location, before creating a
fresh, empty database, and will log a warning. If your RabbitMQ
installation contains important data then we recommend you contact
support at rabbitmq.com for assistance with the upgrade.

Important notes on the AMQP 0-9-1 semantic changes

This release incorporates a number of semantic changes to the broker
behaviour which bring the broker more in-line with the AMQP 0-9-1
specification. We don't think any of these changes are going to be a
big problem for anyone, and will probably be irrelevant for most
people. In almost all cases they're tightening up or tidying up edge
cases where the 0-8 spec was incomplete or specified something
unhelpful. However, it's probably worth reading the list below to make
absolutely sure you're not depending on any of our existing weird

Reuse of delivery tags

In previous versions of RabbitMQ, you could ack the same message with
the same delivery tag multiple times. In 1.8.0 this will cause a
not-found exception. Note that if a message is redelivered for any
reason it will get a new delivery tag so you can ack it again.

Exchange equivalence

In previous versions of RabbitMQ you could actively declare an
exchange with one set of durable and auto-delete parameters, then
actively declare it again with different parameters and get the same
exchange back. This now causes a precondition_failed exception, as it
would if the type does not match. Note that with the old behaviour the
exchange did not actually change to match the new parameters; you just
got back something that was not what you asked for.

In previous versions, when passively declaring an exchange, the type
parameter was checked (but not the durable and auto-delete
parameters).  Now only the name is checked. Passive declaration cannot
create an exchange, and exchanges are only identified by their
name. Therefore it does not make sense to require the other parameters
of exchange.declare to match the exchange declaration in the passive

Queue equivalence

Similarly, when actively redeclaring a queue you could vary the
durable and auto-delete parameters and get back a queue which did not
match what you asked for. Again, this is now causes a
precondition_failed exception.  Likewise, passive declaration of
queues only needs to match on the queue name, not any other

Purging unacknowledged messages

When queue.purge is called, messages which had been send but not
acknowledged used to be purged. Now they are not. This makes much more
sense as consumers from a queue may have no idea whether or not a
queue has been purged by some other client.

Binding durable queues to transient exchanges

This used not to be permitted. Now it is. The binding is considered

Queue exclusivity enforcement

In previous versions of RabbitMQ, an exclusive queue could still be
accessed by other connections for (un)binding or basic.get. This is now
not permitted.

Also, an exclusive queue would continue to exist for a short time after
the connection was closed. It's now deleted while the connection is
being closed (assuming that's happening in an orderly manner).

More information about the rabbitmq-discuss mailing list