[rabbitmq-discuss] intermittent erl.exe crash

[JD Conley]

> 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. A client
created a binding, then some time went by and it was time to remove the
binding, probably by a different client, that maybe wasn't connected yet and
doesn't know the binding was destroyed. There is a web farm with long
running connections/sessions to the Rabbitmq cluster.

I'm using this as a message passing system for a web application written
using the official .NET client. I have a Fanout exchange and a queue per
user session. Sort of like a chat room, when a user 'joins' her queue is
bound to the routing key for that 'room'. Users are long polling my web app,
which is doing a BasicConsume through a shared EventingBasicConsumer during
the 60 second polling period, and a BasicCancel when the poll is completed.
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.
:)

> 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. 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. 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.

> >> Is there anything in the sasl log?
> >
> > No. It's using guest only.
> 
> I mean the rabbit-sasl.log; "SASL" in this case stands for Erlang's
> "System Architecture Support Libraries" - nothing to do with
> authentication.

Hah! Oops. Too much network protocol background in my past. The answer is
the same, even without the part of me looking like an idiot. The log is
empty.

-JD