Changes in 2.1 Since 2.0

Spring AMQP now uses the 5.4.x version of the amqp-client library provided by the RabbitMQ team. This client has auto-recovery configured by default. See RabbitMQ Automatic Connection/Topology recovery.

Certain classes have moved to different packages. Most are internal classes and do not affect user applications. Two exceptions are ChannelAwareMessageListener and RabbitListenerErrorHandler. These interfaces are now in org.springframework.amqp.rabbit.listener.api.

Channels enabled for publisher confirmations are not returned to the cache while there are outstanding confirmations. See Correlated Publisher Confirms and Returns for more information.

You can now use the listener container factories to create any listener container, not only those for use with @RabbitListener annotations or the @RabbitListenerEndpointRegistry. See Using Container Factories for more information.

ChannelAwareMessageListener now inherits from MessageListener.

A BrokerEventListener is introduced to publish selected broker events as ApplicationEvent instances. See Broker Event Listener for more information.

The RabbitAdmin discovers beans of type Declarables (which is a container for Declarable - Queue, Exchange, and Binding objects) and declare the contained objects on the broker. Users are discouraged from using the old mechanism of declaring <Collection<Queue>> (and others) and should use Declarables beans instead. By default, the old mechanism is disabled. See Declaring Collections of Exchanges, Queues, and Bindings for more information.

AnonymousQueue instances are now declared with x-queue-master-locator set to client-local by default, to ensure the queues are created on the node the application is connected to. See Configuring the Broker for more information.

You can now configure the RabbitTemplate with the noLocalReplyConsumer option to control a noLocal flag for reply consumers in the sendAndReceive() operations. See Request/Reply Messaging for more information.

CorrelationData for publisher confirmations now has a ListenableFuture, which you can use to get the acknowledgment instead of using a callback. When returns and confirmations are enabled, the correlation data, if provided, is populated with the returned message. See Correlated Publisher Confirms and Returns for more information.

A method called replyTimedOut is now provided to notify subclasses that a reply has timed out, allowing for any state cleanup. See Reply Timeout for more information.

You can now specify an ErrorHandler to be invoked when using request/reply with a DirectReplyToMessageListenerContainer (the default) when exceptions occur when replies are delivered (for example, late replies). See setReplyErrorHandler on the RabbitTemplate. (Also since 2.0.11).

We introduced a new Jackson2XmlMessageConverter to support converting messages from and to XML format. See Jackson2XmlMessageConverter for more information.

The RabbitManagementTemplate is now deprecated in favor of the direct com.rabbitmq.http.client.Client (or com.rabbitmq.http.client.ReactorNettyClient) usage. See Management REST API for more information.

The listener container factory can now be configured with a RetryTemplate and, optionally, a RecoveryCallback used when sending replies. See Enable Listener Endpoint Annotations for more information.

@RabbitListener methods can now return ListenableFuture<?> or Mono<?>. See Asynchronous @RabbitListener Return Types for more information.

By default, the RabbitConnectionFactoryBean now calls enableHostnameVerification(). To revert to the previous behavior, set the enableHostnameVerification property to false.

The CachingConnectionFactory now unconditionally disables auto-recovery in the underlying RabbitMQ ConnectionFactory, even if a pre-configured instance is provided in a constructor. While steps have been taken to make Spring AMQP compatible with auto recovery, certain corner cases have arisen where issues remain. Spring AMQP has had its own recovery mechanism since 1.0.0 and does not need to use the recovery provided by the client. While it is still possible to enable the feature (using cachingConnectionFactory.getRabbitConnectionFactory() .setAutomaticRecoveryEnabled()) after the CachingConnectionFactory is constructed, we strongly recommend that you not do so. We recommend that you use a separate RabbitMQ ConnectionFactory if you need auto recovery connections when using the client factory directly (rather than using Spring AMQP components).

The default ConditionalRejectingErrorHandler now completely discards messages that cause fatal errors if an x-death header is present. See Exception Handling for more information.

A new ImmediateRequeueAmqpException is introduced to notify a listener container that the message has to be re-queued. To use this feature, a new ImmediateRequeueMessageRecoverer implementation is added.

See Message Listeners and the Asynchronous Case for more information.