RabbitMQ doesn’t actually speak AMQP 1.0; it speaks AMQP 0-9-1. The "AMQP 1.0 Support" you’re seeing is about enabling the interoperability layer that lets other systems speaking AMQP 1.0 connect to your RabbitMQ instance.
Let’s see this in action. Imagine you have a separate service, let’s call it amqp10-client, that does speak AMQP 1.0. You want this client to send messages to a queue named my-amqp091-queue in your RabbitMQ.
First, you need to enable the AMQP 1.0 plugin on RabbitMQ. This is typically done via the RabbitMQ management interface or the command line.
On the command line, it looks like this:
sudo rabbitmq-plugins enable rabbitmq_amqp10
This command loads the necessary modules into the RabbitMQ broker. Once enabled, you’ll need to restart RabbitMQ for the changes to take effect.
sudo systemctl restart rabbitmq-server
Now, your amqp10-client can connect. The crucial part is the connection string, which will look something like this, assuming your RabbitMQ is running on localhost and the AMQP 1.0 endpoint is exposed on the default port 5672:
amqp://localhost:5672
However, the AMQP 1.0 plugin uses a specific endpoint within RabbitMQ. It’s not just a matter of connecting to the standard AMQP port. The plugin creates a listener on the same port, but it distinguishes AMQP 1.0 traffic. For a client to send to my-amqp091-queue, it might use a URL like this:
amqp://localhost:5672/amq/queue/my-amqp091-queue
Here, /amq/queue/ is part of the default AMQP 1.0 endpoint path that the plugin exposes. The actual queue my-amqp091-queue must already exist in RabbitMQ as an AMQP 0-9-1 queue. The plugin acts as a translator, taking the incoming AMQP 1.0 messages and routing them to the appropriate AMQP 0-9-1 entities (exchanges, queues) within RabbitMQ.
The problem this solves is bridging the gap between older systems using AMQP 0-9-1 (like many microservices) and newer systems or external services that have adopted AMQP 1.0. AMQP 1.0 is a more robust, session-oriented protocol designed for distributed systems, offering features like enhanced error handling, load balancing, and explicit message acknowledgments. By enabling this plugin, RabbitMQ becomes a central hub that can ingest messages from both worlds.
Internally, the rabbitmq_amqp10 plugin implements the AMQP 1.0 protocol specification. When an AMQP 1.0 client connects, the plugin intercepts the connection. It then translates AMQP 1.0 concepts—like senders, receivers, links, and sessions—into their AMQP 0-9-1 equivalents. For instance, an AMQP 1.0 sender sending a message to a specific address will be mapped by the plugin to a publish operation on an AMQP 0-9-1 exchange, with the target queue determined by the address. Conversely, an AMQP 0-9-1 consumer reading from a queue will have its messages delivered to an AMQP 1.0 receiver.
The exact levers you control are primarily through the configuration of the AMQP 1.0 endpoint. While the default path /amq/queue/ works for many cases, you can customize this. In your RabbitMQ configuration file (e.g., rabbitmq.conf), you might see settings like:
amqp10.listener.port = 5672
amqp10.listener.host = 0.0.0.0
amqp10.listener.path = /my/custom/amqp10/path
These settings allow you to bind the AMQP 1.0 listener to a specific port and host, and crucially, to define a custom path prefix. If you set amqp10.listener.path to /my/custom/amqp10/path, your AMQP 1.0 clients would then need to connect using an address like:
amqp://localhost:5672/my/custom/amqp10/path/queue/my-amqp091-queue
This path customization is essential for scenarios where you might have multiple brokers or services on the same network, allowing for clearer routing and avoiding port conflicts if you were to run multiple AMQP 1.0 endpoints. The plugin handles the mapping of the rest of the address (e.g., /queue/my-amqp091-queue) to actual RabbitMQ destinations.
A detail often overlooked is how acknowledgments are handled across the protocol boundary. When an AMQP 1.0 client sends a message with a "transfer" command and expects an acknowledgment, the AMQP 1.0 plugin will receive this. It then translates this into an AMQP 0-9-1 acknowledgment after the message has been successfully routed to the target AMQP 0-9-1 queue and persisted (if configured to do so). This ensures that the AMQP 1.0 client only confirms delivery once RabbitMQ has committed to holding the message, providing a strong consistency guarantee.
The next concept you’ll likely encounter is managing the virtual hosts and permissions for AMQP 1.0 clients, as these are also translated from the AMQP 0-9-1 security model.