Introduction

RabbitTemplate does not automatically create arbitrary queues just because you call convertAndSend. If you publish to a routing key that names a queue and that queue does not exist, RabbitMQ will not silently create it for you.

What Spring can do automatically is declare queues, exchanges, and bindings that you have explicitly defined as beans, usually through RabbitAdmin at application startup. That is a very different behavior from "create whatever queue I publish to."

What Actually Happens on Send

A common send call looks like this:

rabbitTemplate.convertAndSend("", "orders", "payload");

With the default exchange, the routing key is treated like the queue name. But if orders does not exist, the broker does not create it on demand.

Depending on how the publish is configured, the message may be dropped or returned as unroutable.

So if your goal is automatic availability of a known queue, you should declare that queue explicitly before sending.

Spring's Usual Solution: Declare the Queue as a Bean

The standard Spring AMQP approach is to define the queue in configuration and let RabbitAdmin declare it when the application starts.

1import org.springframework.amqp.core.Queue;
2import org.springframework.amqp.rabbit.core.RabbitAdmin;
3import org.springframework.context.annotation.Bean;
4import org.springframework.context.annotation.Configuration;
5
6@Configuration
7public class RabbitConfig {
8
9    @Bean
10    public Queue ordersQueue() {
11        return new Queue("orders", true);
12    }
13}

With the right Spring Boot setup, RabbitAdmin will detect that bean and declare it against RabbitMQ when the connection is established.

Then sending is straightforward:

rabbitTemplate.convertAndSend("", "orders", "payload");

That works because the queue was already declared, not because RabbitTemplate invented it at send time.

Programmatic Declaration Before Send

If the queue name is dynamic and known only at runtime, you can declare it programmatically before publishing.

1import org.springframework.amqp.core.Queue;
2import org.springframework.amqp.rabbit.core.RabbitAdmin;
3
4public void sendToDynamicQueue(String queueName, String payload, RabbitAdmin rabbitAdmin) {
5    rabbitAdmin.declareQueue(new Queue(queueName, true));
6    rabbitTemplate.convertAndSend("", queueName, payload);
7}

That is the closest thing to "create on send," but notice the queue is still being declared explicitly.

Dynamic Queues Need Restraint

Creating queues dynamically can be useful for tenant isolation, temporary workflows, or testing. But it also creates operational risk.

Ask these questions first:

• who cleans up unused queues
• should they be durable or auto-delete
• how many queues might be created over time
• do you also need dynamic bindings and exchanges

A system that casually creates unbounded queues can become difficult to operate and monitor.

Detect Unroutable Publishes

If you want strong visibility when the target queue is missing or not bound as expected, use publisher returns and the mandatory flag rather than assuming send always succeeds.

That gives you feedback when the message could not be routed instead of letting the issue stay silent.

Common Pitfalls

The biggest mistake is believing RabbitTemplate.convertAndSend(...) automatically creates the queue named by the routing key. It does not.

Another common issue is defining a Queue bean but not having the declaration infrastructure active, then assuming Spring has already created the broker resources.

People also create dynamic queues without thinking about cleanup, durability, or exchange bindings.

Finally, do not confuse queue declaration with successful routing. A declared queue still needs the correct exchange and binding setup for non-default exchange publishes.

Summary

• 'RabbitTemplate does not auto-create arbitrary queues on publish.'
• Spring can auto-declare queues that you define explicitly as beans.
• For runtime-created queues, declare them programmatically before sending.
• The default exchange uses the queue name as routing key, but the queue must already exist.
• Use publisher returns or mandatory publishing when you need visibility into unroutable messages.
• Treat dynamic queue creation as an intentional resource-management decision.