Exchange to Exchange Bindings

Overview

In AMQP 0-9-1 the queue.bind method binds a queue to an exchange so that messages flow (subject to various criteria) from the exchange (the source) to the queue (the destination). We have introduced an exchange.bind method which binds one exchange to another exchange. The binding is semantically identical to exchange-to-queue bindings: unidirectional, binding keys and exchange types operate as normal, but both endpoints (the source and destination) of the binding are exchanges. This allows far richer routing topologies to be created. Note the source and destination fields in the exchange.bind method reflect the flow of messages: from the exchange at the source, and to the exchange at the destination.

Just like with queue.bind, multiple distinct bindings can be created between the same binding-endpoints. We detect and eliminate cycles during message delivery, and ensure that transitively, over any routing topology, for every queue to which a given message is routed, each queue will receive exactly one copy of that message. Exchanges which are declared as auto-delete will still be removed when all their bindings are removed, regardless of whether those bindings are to queues or exchanges. Note that an auto-delete exchange will only be deleted when bindings for which the exchange is the source are removed: if you add exchange-to-exchange bindings for which the given exchange is the destination then that exchange will not be auto-deleted on removal of those bindings.

Java Client Example

Use the Channel#exchangeBind method. The following example binds an exchange "destination" to "source" with routing key "routingKey".

Channel ch = conn.createChannel();
ch.exchangeBind("destination", "source", "routingKey");

.NET Client Example

Use the IModel#ExchangeBind method. The following example binds an exchange "destination" to "source" with routing key "routingKey".

var ch = conn.CreateModel();
ch.ExchangeBind("destination", "source", "routingKey");