[rabbitmq-discuss] Fwd: .Net RabbitMQ.Client Issue: Deadlock on ConnectionShutdown

Mon Sep 24 11:03:07 BST 2012

On 21/09/12 15:48, Derek Greer wrote:
> As far as considering connection renewal rather than channel renewal, I
> don't understand how this would be possible. You yourself said:

I propose that you look at the problem from another perspective. If a
connection crashes then forget about that connection and all the
channels contained in it. The library will clean them up. Return to the
point of control where the connection was established and reconnect and
re-establish brand new AMQP subscriptions.

> Again, the problem I'm trying to address is to model a Subscription
> which can be cancelled on demand (i.e. the user wants to maintain the
> connection, but wants to unsubscribe from receiving a given message
> type), and which can be renewed when a new connection is obtained.

We are using the word "subscription" for at least two different things:
AMQP subscriptions (which cannot be renewed)
The view that your user sees (and cope with reconnections transparently)

Cancelling an AMQP subscription is simple, because there is an explicit
method for it. "Renewing" an AMQP subscription is not possible. Creating
the illusion of renewable subscriptions is design problem that the
RabbitMQ client library does not address.

>  Using the IModel.ModelShutdown event here isn't what someone would want
> to do from a design perspective, as there are things I want to do on
> connection shutdown that I don't want to do on every model shutdown.  It
> just simply isn't the right event for the case at hand.  I also can't
> just not call IModel.Close() in all cases.
> 
> Bottom line, I see a design flaw here that needs to be recognized and
> addressed.  

The absence if renewable subscriptions may well be considered a flaw.
Instead of trying to be all things to all people, the library instead
offers the building blocks to build solutions that can hopefully suit
every user. Signalling connection and channel lifetime events is an
important component building block.

> Speaking of which, this mailing list is a horrible way to deal with
> product specific bug reports.  Why doesn't your team use github or
> some other facility which has a proper bug tracking system?

We thank you for your feedback and will take it into consideration in
any future decision about this matter.

-Emile