[rabbitmq-discuss] ANN Bunny 1.0.0.rc1

Wed Oct 2 13:27:45 BST 2013

(02/10/13 12:30), Michael Klishin wrote:
> On oct 2, 2013, at 2:09 p.m., Ceri Storey <ceri at lshift.net> wrote:
>
>> would it be possible to add a
>> callback for connection-level errors, rather than having them thrown on
>> thread that created the Bunny session?
> Connection-level exceptions *are* exceptions. They are rare, should be
> very visible and cannot be recovered from.
Sure, I'd agree.
> What are the benefits of using callbacks? It's easy to forget to define one
> while exceptions are very visible.
I wouldn't suggest that we change the default behavior, as the current
halt-and-catch-fire behavior is a reasonable default.

The only reason I take issue with it is one of safety--at the moment,
because the exceptions are thrown asynchronously to a "main" thread, you
have to ensure that you're within a given dynamic extent during the
entire time that you have an open Bunny session. Also, we need to ensure
that any sensitive operations (ie: ones that you really don't want to
have a random exception fire in the middle of) happen off that main
thread. So, to give a more concrete example:

We use Rack's rackup command to run our web application. So in a sense,
you have a kind of inversion of control. We construct our application
from a wiring module which returns a Rack-compatible callable. However,
once control has returned to rackup, we no longer have control over the
main thread of the application.  So, currently, if an AMQP exception
happens in the process, then the rackup process exits with a failure
status, and would need to be restarted.

Even if we boot a web server ourselves, if we run that (again) in the
main thread and an AMQP exception happens, then it's possible that the
server will be left in a state that it can't recover from. Eg: Listening
on a given port, but with no way to re-start the process that accepts
connections. Again, we could handle that in a separate thread, but I'd
be reasonably confident that we won't be the only ones impacted by this.

So this would be more of an optional extra along the lines of the
shutdown listener in the Java client for those who need the extra control.