SpringBoot - RabbitMQ

RabbitMQ support

RabbitMQ is a lightweight, reliable, scalable, and portable message broker based on the AMQP
protocol. Spring uses RabbitMQ to communicate through the AMQP protocol.
RabbitMQ configuration is controlled by external configuration properties in spring.rabbitmq.*. For
example, you might declare the following section in application.properties:

spring.rabbitmq.host=localhost
spring.rabbitmq.port=5672
spring.rabbitmq.username=admin
spring.rabbitmq.password=secret

Alternatively, you could configure the same connection using the addresses attribute:

spring.rabbitmq.addresses=amqp://admin:secret@localhost

If a ConnectionNameStrategy bean exists in the context, it will be automatically used to name
connections created by the auto-configured ConnectionFactory. See RabbitProperties for more of the
supported options.

Sending a Message

Spring’s AmqpTemplate and AmqpAdmin are auto-configured, and you can autowire them directly into your own beans, as shown in the following example:

import org.springframework.amqp.core.AmqpAdmin;
import org.springframework.amqp.core.AmqpTemplate;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
@Component
public class MyBean {
private final AmqpAdmin amqpAdmin;
private final AmqpTemplate amqpTemplate;
@Autowired
public MyBean(AmqpAdmin amqpAdmin, AmqpTemplate amqpTemplate) {
this.amqpAdmin = amqpAdmin;
this.amqpTemplate = amqpTemplate;
}
// ...
}

RabbitMessagingTemplate can be injected in a similar manner. If a MessageConverter
bean is defined, it is associated automatically to the auto-configured AmqpTemplate.

If necessary, any org.springframework.amqp.core.Queue that is defined as a bean is automatically
used to declare a corresponding queue on the RabbitMQ instance.

To retry operations, you can enable retries on the AmqpTemplate (for example, in the event that the
broker connection is lost):

spring.rabbitmq.template.retry.enabled=true
spring.rabbitmq.template.retry.initial-interval=2s

Retries are disabled by default. You can also customize the RetryTemplate programmatically by
declaring a RabbitRetryTemplateCustomizer bean.


If you need to create more RabbitTemplate instances or if you want to override the default, Spring
Boot provides a RabbitTemplateConfigurer bean that you can use to initialize a RabbitTemplate with
the same settings as the factories used by the auto-configuration.

Receiving a Message

When the Rabbit infrastructure is present, any bean can be annotated with @RabbitListener to
create a listener endpoint. If no RabbitListenerContainerFactory has been defined, a default
SimpleRabbitListenerContainerFactory is automatically configured and you can switch to a direct
container using the configprop:spring.rabbitmq.listener.type[] property. If a MessageConverter or a
MessageRecoverer bean is defined, it is automatically associated with the default factory.

The following sample component creates a listener endpoint on the someQueue queue:
@Component
public class MyBean {
@RabbitListener(queues = "someQueue")
public void processMessage(String content) {
// ...
}
}

If you need to create more RabbitListenerContainerFactory instances or if you want to override the
default, Spring Boot provides a SimpleRabbitListenerContainerFactoryConfigurer and a
DirectRabbitListenerContainerFactoryConfigurer that you can use to initialize a
SimpleRabbitListenerContainerFactory and a DirectRabbitListenerContainerFactory with the same
settings as the factories used by the auto-configuration.

It does not matter which container type you chose. Those two beans are exposed
by the auto-configuration.

For instance, the following configuration class exposes another factory that uses a specific
MessageConverter:


@Configuration(proxyBeanMethods = false)
static class RabbitConfiguration {
@Bean
public SimpleRabbitListenerContainerFactory myFactory(
SimpleRabbitListenerContainerFactoryConfigurer configurer) {
SimpleRabbitListenerContainerFactory factory =
new SimpleRabbitListenerContainerFactory();
configurer.configure(factory, connectionFactory);
factory.setMessageConverter(myMessageConverter());
return factory;
}
}

Then you can use the factory in any @RabbitListener-annotated method, as follows:

@Component
public class MyBean {
@RabbitListener(queues = "someQueue", containerFactory="myFactory")
public void processMessage(String content) {
// ...
}
}

You can enable retries to handle situations where your listener throws an exception. By default,
RejectAndDontRequeueRecoverer is used, but you can define a MessageRecoverer of your own. When retries are exhausted, the message is rejected and either dropped or routed to a dead-letter
exchange if the broker is configured to do so. By default, retries are disabled. You can also
customize the RetryTemplate programmatically by declaring a RabbitRetryTemplateCustomizer bean.

By default, if retries are disabled and the listener throws an exception, the delivery
is retried indefinitely. You can modify this behavior in two ways: Set the
defaultRequeueRejected property to false so that zero re-deliveries are attempted
or throw an AmqpRejectAndDontRequeueException to signal the message should be
rejected. The latter is the mechanism used when retries are enabled and the
maximum number of delivery attempts is reached.