[rabbitmq-discuss] intermittent erl.exe crash

Matthias Radestock matthias at lshift.net
Thu Nov 5 19:29:48 GMT 2009


JD,

JD Conley wrote:
>> Why are your clients trying to unbind non-existing bindings?
> 
> They don't know the bindings are non-existent since the queues/exchange in
> question aren't durable and, say, a server might crash and restart.

Rabbit doesn't usually crash ;)

> I persist the list of currently bound routing keys in a database and a
> binding will usually last a few minutes before it is unbound. There is a
> background cleanup process that runs and removes bindings and destroys
> queues after users haven't polled in a while.
> 
> If there's a better way to do something like this, I'm open to suggestion.

I think what you are doing is fine. One possible improvement is to 
(re)declare the queues/bindings just before attempting to delete them. 
It's a cheap operation for the server if the entities do exist already - 
which is the common case - and it prevents the errors when they don't.

One possible extension of RabbitMQ could allow queues to have a 
"automatically delete if idle for longer than X" setting. That would 
actually be quite easy to implement and is a natural extension of the 
existing exclusivity and auto-delete flags. Would that work for you or 
do you actually need an idle timeout for *bindings*? Those would be a 
lot harder to implement.

>> The AMQP spec requires that this results in an error.
> 
> That's fine, but that doesn't seem critical enough for the connection to
> have to drop.

Actually, not_found (404) is defined to be *soft* error, which means it 
only closes the channel, not the connection. So I suspect your 
application code is tripping over the channel error and causing the 
connection to close.

> As a newcomer in the space, it's ironic to me that I can declare
> duplicate queues and exchanges without any errors but not silently 
> remove a binding that doesn't exist.

Declaration is an assertion of existence, and hence is idempotent - you 
can assert the existence of something as many times as you like; you 
cannot create duplicates. Now, deletion/unbind should really be an 
assertion of non-existence and hence be idempotent too, but 
unfortunately it isn't. One day that will hopefully get fixed in the 
protocol spec.

> It would be great if it were an option to behave like the .NET
> generic Dictionary that returns 'true' on remove if there was
> actually something there, or silently ignores the call and returns 
> 'false' if not. Is there a DoesBindingExist method I can use to do
> things cleanly today? I didn't see one.

There is no such mechanism. Ideally the protocol would allow the listing 
of existing entities. RabbitMQ currently allows that via the 
'rabbitmqctl list_*' commands, but that is outside the protocol and not 
designed for high rates of execution.


Regards,

Matthias.




More information about the rabbitmq-discuss mailing list