[rabbitmq-discuss] What is internal parameter of exchange.declare for?

[Simon MacMullen]

On 05/03/2011 1:07AM, Alexandru Scvorţov wrote:
> Hi,
>
> The first hint is in rabbitmqctl's manpage:
>    http://www.rabbitmq.com/man/rabbitmqctl.1.man.html
>
>    ``internal
>      Whether the exchange is internal, i.e. cannot be directly published to
>      by a client.''
>
> Which raises the question, ``Why on earth would you have an exchange
> that cannot be published to?''.  The answer is exchange-to-exchange
> bindings:
>    http://www.rabbitmq.com/extensions.html#exchange-bindings
>
> And here's the blogpost that sheds a little more light on the subject:
>    http://www.rabbitmq.com/blog/2010/10/19/exchange-to-exchange-bindings/

Some history:

"internal" was originally specified in AMQP 0-8. The 0-8 spec says:

       If set, the exchange may not be used directly by publishers, but
       only when bound to other exchanges. Internal exchanges are used to
       construct wiring that is not visible to applications.

This was deprecated in AMQP 0-9-1, which is why it shows up as 
"reserved-3". It was deprecated since neither AMQP 0-8 or 0-9-1 have the 
concept of exchange to exchange bindings (despite the strong 
implications of the above quote!)

When we implemented exchange to exchange bindings as an extension to 
AMQP 0-9-1 we decided to implement internal exchanges despite the 
deprecation, as they are now useful.

Similarly, "reserved-2" in 0-9-1's exchange.declare corresponds to 0-8's 
"auto-delete" field. This means "delete the exchange when something has 
bound to it and then everything has unbound from it", which again only 
really makes sense in the context of exchange to exchange bindings, so 
again we've effectively undeprecated it.

"reserved-1" corresponds to the "ticket" field that's on most methods 
which was an attempt to optimise access control. We still ignore that.

Cheers, Simon