2. What's New

2.1 Changes in 1.3 Since 1.2

2.1.1 Listener Concurrency

The listener container now supports dynamic scaling of the number of consumers based on workload, or the concurrency can be programmatically changed without stopping the container. See Section 3.12, “Listener Concurrency”.

2.1.2 Listener Queues

The listener container now permits the queue(s) on which it is listening to be modified at runtime. Also, the container will now start if at least one of its configured queues is available for use. See Section 3.14, “Listener Container Queues”

This listener container will now redeclare any auto-delete queues during startup. See the section called “'auto-delete' Queues”.

2.1.3 Consumer Priority

The listener container now supports consumer arguments, allowing the x-priority argument to be set. See Section 3.5.2, “Asynchronous Consumer”.

2.1.4 Exclusive Consumer

The SimpleMessageListenerContainer can now be configured with a single exclusive consumer, preventing other consumers from listening to the queue. See Section 3.13, “Exclusive Consumer”.

2.1.5 Rabbit Admin

It is now possible to have the Broker generate the queue name, regardless of durable, autoDelete and exclusive settings. See Section 3.8, “Configuring the broker”.

2.1.6 Direct Exchange Binding

Previously, omitting the key attribute from a binding element of a direct-exchange configuration caused the queue or exchange to be bound with an empty string as the routing key. Now it is bound with the the name of the provided Queue or Exchange. Users wishing to bind with an empty string routing key need to specify key="".

2.1.7 AMQP Template

The AmqpTemplate now provides several synchronous receiveAndReply methods. These are implemented by the RabbitTemplate. For more information see Section 3.5, “Receiving messages”.

The RabbitTemplate now supports configuring a RetryTemplate to attempt retries (with optional back off policy) for when the broker is not available. For more information see Section 3.3.1, “Adding Retry Capabilities”.

2.1.8 Caching Connection Factory

The caching connection factory can now be configured to cache Connections and their Channels instead of using a single connection and caching just Channels. See Section 3.2, “Connection and Resource Management”.

2.1.9 Binding Arguments

The <exchange>'s <binding> now supports parsing of the <binding-arguments> sub-element. The <headers-exchange>'s <binding> now can be configured with a key/value attribute pair (to match on a single header) or with a <binding-arguments> sub-element, allowing matching on multiple headers; these options are mutually exclusive. See Section 3.8, “Configuring the broker”.

2.1.10 Routing Connection Factory

A new SimpleRoutingConnectionFactory has been introduced, to allow configuration of ConnectionFactories mapping to determine the target ConnectionFactory to use at runtime. See Section 3.2.2, “Routing Connection Factory”.

2.1.11 MessageBuilder and MessagePropertiesBuilder

"Fluent APIs" for building messages and/or message properties is now provided. See Section 3.4.1, “Message Builder API”.

2.1.12 RetryInterceptorBuilder

A "Fluent API" for building listener container retry interceptors is now provided. See Section 3.15.2, “Failures in Synchronous Operations and Options for Retry”.

2.1.13 RepublishMessageRecoverer

This new MessageRecoverer is provided to allow publishing a failed message to another queue (including stack trace information in the header) when retries are exhausted. See Section 3.15.3, “Message Listeners and the Asynchronous Case”.

2.2 Changes to 1.2 Since 1.1

2.2.1 RabbitMQ Version

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.

2.2.2 Rabbit Admin

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.

2.2.3 Rabbit Template

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.

2.2.4 JSON Message Converters

A Jackson 2.x MessageConverter is now provided, along with the existing converter that uses Jackson 1.x.

2.2.5 Automatic Declaration of Queues, etc

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”.

2.2.6 AMQP Remoting

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”

2.2.7 Requested Heart Beats

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.

2.3 Changes to 1.1 Since 1.0

2.3.1 General

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.

2.3.2 AMQP Log4j Appender

Adds an option to support adding a message id to logged messages.

Adds an option to allow the specification of a Charset name to be used when converting Strings to byte[].