[rabbitmq-discuss] RabbitMQ 1.8.0 release

[Kevin A. Smith]

Congrats on 1.8.0! Very interested to dig into the pluggable persistence API now that it's stabilized.

I recently had some issues with Maven and Sonatype during the last Riak release. If you're seeing bad checksum errors when attempting to close a staging repo then you need to update Maven. There was a bug which was apparently triggered by some infrastructure updates Sonatype did recently.

--Kevin
On Jun 16, 2010, at 11:10 AM, Matthew Sackman wrote:

> 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.
> 
> 
> Regards,
> 
> The RabbitMQ Team
> 
> 
> 
> Release: RabbitMQ 1.8.0
> 
> Release Highlights
> ==================
> 
> server
> ------
> bug fixes
> - prevent a change in host name from preventing RabbitMQ from being
>  restarted.
> - ensure that durable exclusive queues do not survive a restart of the
>  broker.
> - 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.
> 
> enhancements
> ------------
> - introduce a pluggable exchange type API permitting plugins to the
>  broker to define new exchange types which can then be used by
>  clients.
> - 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
>    queue.unbind.
>  + 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
>  http://www.rabbitmq.com/extensions.html#memsup
> - 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
>  http://www.rabbitmq.com/pacemaker.html).
> 
> 
> 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
>  wrapping.
> - be consistent about naming conventions.
> 
> enhancements
> - 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
>  exceptions.
> - 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.
> 
> enhancements
> - 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
>  exceptions.
> 
> 
> code generation
> ---------------
> enhancements
> - 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.
> 
> enhancements
> - source rpm (.src.rpm) packages are now available
> - rpm packages are now noarch, matching the debs
> 
> 
> Upgrading
> =========
> 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
> behaviour.
> 
> 
> 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
> case.
> 
> 
> 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
> parameters.
> 
> 
> 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
> transient.
> 
> 
> 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).
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss