[rabbitmq-discuss] binding_not_found

[Simon MacMullen]

On 20/09/12 10:44, Ben Hood wrote:
> Hi,

Hi.

> This is probably quite a stupid question, but I was wondering under
> what conditions a binding_not_found exception can occur in a 2.8.6
> broker.

I assume you mean "...in response to queue.bind". There is - of course - 
a completely obvious case in response to queue.unbind.

> A very cursory glance at the source indicates that if I try to bind a
> durable queue to a durable exchange, and if in addition to this, a
> binding already exists in the database, then the call to add a binding
> will return a binding_not_found:
>
> case (not (SrcDurable andalso DstDurable) orelse
>            mnesia:read({rabbit_durable_route, B}) =:= []) of
>          true  ->  ...
>          false ->  rabbit_misc:const({error, binding_not_found})
> end.
>
> Do I see this correctly?

Not quite. The extra information is that in order to get there, we have 
to have gone past a point in add/2 where we already know that there is 
no binding in the rabbit_route table. So we only return 
binding_not_found if the binding is in rabbit_durable_route but not 
rabbit_route (and the binding is between two durable things and thus 
should be durable).

The idea is that rabbit_{route,queue} contains all effective 
bindings/queues, and rabbit_durable_{route,queue} contains all durable 
bindings/queues. It's obvious how something can be effective but not 
durable, but how can it be durable but not effective?

The answer is: when it points to a durable queue in a cluster which is 
located on a node which is down (or mirrored across a set of nodes all 
of which are down). In this circumstance (only) we will return NOT_FOUND 
to queue.declare and queue.bind operations.

And yes, there is already a bug open to make this clearer.

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, VMware