Spring AMQP now using RabbitMQ 3.1.x by default (but retains
compatibility with earlier versions). Certain deprecations have
been added for features no longer supported by RabbitMQ 3.1.x -
federated exchanges and the immediate property on
the RabbitTemplate.
The RabbitAdmin now provides an option to allow
exchange, queue, and binding declarations to continue when a declaration
fails. Previously, all declarations stopped on a failure. By setting
ignore-declaration-exceptions, such exceptions are logged (WARN),
but further declarations continue. An example where this might be useful is
when a queue declaration fails because of a slightly different ttl
setting would normally stop other declarations from proceeding.
The RabbitAdmin now provides an additional method
getQueueProperties(). This can be used to determine if a queue
exists on the broker (returns null for a non-existent queue). In addition,
the current number of messages in the queue, as well as the current number
of consumers is returned.
Previously, when using the ...sendAndReceive() methods were used
with a fixed reply queue, two custom headers were used for correlation
data and to retain/restore reply queue information. With this release, the
standard message property correlationId is used by default,
although the user can specifiy a custom property to use instead. In addition,
nested replyTo information is now retained internally in the template,
instead of using a custom header.
The immediate property is deprecated; users must not set this
property when using RabbitMQ 3.0.x or greater.
A Jackson 2.x MessageConverter is now provided, along
with the existing converter that uses Jackson 1.x.
Previously, when declaring queues, exchanges and bindings, it was not possible
to define which connection factory was used for the declarations, each
RabbitAdmin would declare all components using
its connection.
Starting with this release, it is now possible to limit declarations to specific
RabbitAdmin instances. See Section 3.8.1, “Conditional Declaration”.
Facilities are now provided for using Spring Remoting techniques, using AMQP as the transport for the RPC calls. For more information see Section 3.7.2, “Spring Remoting with AMQP”
Several users have asked for the underlying client connection factory's requestedHeartBeats
property to be exposed on the Spring AMQP CachingConnectionFactory. This is
now available; previously, it was necessary to configure the AMQP client factory as
a separate bean and provide a reference to it in the CachingConnectionFactory.
Spring-AMQP is now built using gradle.
Adds support for publisher confirms and returns.
Adds support for HA queues, and broker failover.
Adds support for Dead Letter Exchanges/Dead Letter Queues.