Integrate Spring AMQP with RabbitMQ (2026)

Spring AMQP’s integration with RabbitMQ is surprisingly more about managing the connections and channels than the messages themselves, which is where most people get stuck.

Let’s see it in action. Imagine a simple producer and consumer.

First, the producer’s setup:

spring:
  rabbitmq:
    host: localhost
    port: 5672
    username: user
    password: password
    virtual-host: /
    template:
      exchange: my-exchange
      routing-key: my-routing-key

And the producer code:

@SpringBootApplication
public class ProducerApplication {

    public static void main(String[] args) {
        SpringApplication.run(ProducerApplication.class, args);
    }

    @Bean
    public CommandLineRunner run(RabbitTemplate rabbitTemplate) {
        return args -> {
            String message = "Hello, RabbitMQ!";
            rabbitTemplate.convertAndSend(message);
            System.out.println("Sent: " + message);
        };
    }
}

Now, the consumer’s setup:

spring:
  rabbitmq:
    host: localhost
    port: 5672
    username: user
    password: password
    virtual-host: /
  # This is crucial for the listener container
  amqp:
    listener:
      simple:
        auto-startup: true
        acknowledge-mode: AUTO
        prefetch: 1

And the consumer code:

@SpringBootApplication
public class ConsumerApplication {

    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class, args);
    }

    @RabbitListener(queues = "my-queue")
    public void listen(String message) {
        System.out.println("Received: " + message);
    }

    @Bean
    public Declarables createQueueAndBinding() {
        Queue queue = new Queue("my-queue", false); // durable, autoDelete=false
        TopicExchange exchange = new TopicExchange("my-exchange");
        Binding binding = BindingBuilder.bind(queue).to(exchange).with("my-routing-key");
        return new Declarables(queue, exchange, binding);
    }
}

When you run ProducerApplication, rabbitTemplate.convertAndSend("Hello, RabbitMQ!") will publish the message to my-exchange with my-routing-key. The ConsumerApplication, with its @RabbitListener on my-queue, will pick it up. The Declarables bean ensures that my-queue, my-exchange, and the binding between them exist in RabbitMQ before messages start flowing.

The core problem Spring AMQP solves is abstracting away the raw RabbitMQ client library. Instead of manually creating connections, channels, declaring exchanges/queues, and handling acknowledgments, you work with higher-level constructs like RabbitTemplate and @RabbitListener. The RabbitTemplate handles the intricate dance of acquiring a channel from a connection pool, sending the message, and returning the channel. The @RabbitListener annotation, powered by SimpleMessageListenerContainer, manages a pool of threads that continuously listen on a queue, acquire messages, and dispatch them to your listener method.

The prefetch setting in the consumer’s application.yml is a critical lever. Setting spring.amqp.listener.simple.prefetch: 1 tells the consumer to only request one message from the broker at a time. This is a form of flow control. Without it, or with a high value, the consumer could be overwhelmed if it processes messages slower than the broker can deliver them, leading to excessive memory usage on the consumer side. The acknowledge-mode: AUTO means Spring AMQP automatically acknowledges the message to RabbitMQ as soon as your listener method returns successfully. If your listener throws an exception, the message will be re-queued (depending on broker configuration).

What most people miss is how Spring AMQP manages the lifecycle of the underlying RabbitMQ Connection and Channel objects. The CachingConnectionFactory is the workhorse here. It maintains a pool of Connection objects, and each Connection in turn maintains a pool of Channel objects. When RabbitTemplate needs to send a message, it asks the CachingConnectionFactory for a Channel. The factory tries to get an available Channel from its pool. If one is available, it’s used and then returned after the operation. If not, a new one might be created (up to configured limits). This pooling is what prevents the overhead of establishing a new TCP connection and AMQP channel for every single message, which would be prohibitively slow. The Declarables bean is also a key piece of the puzzle, ensuring that your RabbitMQ infrastructure (exchanges, queues, bindings) is correctly set up before your application starts publishing or consuming, preventing "channel closed" or "not found" errors.

The next logical step is understanding how to handle message failures gracefully, beyond just relying on automatic re-queuing.