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

[Derek Greer]

I appreciate the guidance that you shouldn't call IModel.Close() from a
shutdown callback due to the way the code is currently designed, but I
submit that this is a design flaw within the .Net client and that ideally
you should be able to do this.

As far as considering connection renewal rather than channel renewal, I
don't understand how this would be possible. You yourself said:

*"It is not possible to maintain the previous subscription to the broker*
*and somehow inject a new channel and/or connection into it. You will*
*need to re-establish all contained channels and all associated*
*subscriptions when the connection shuts down."*



If I'm misunderstanding what you mean by this, please provide a bit more
detail as to what you're referring to.


Currently, I'm working around the issue with the following code:

//
------------------------------------------------------------------------------------------
// Closing/disposing channels on IConnection.ConnectionShutdown causes a
deadlock, so
// the ISession.SessionShutdown event is used here to infer a connection
shutdown.
//
------------------------------------------------------------------------------------------
((ConnectionBase) connection).m_session0.SessionShutdown +=
UnexpectedConnectionShutdown;

This obviously isn't ideal, as the SessionShutdown isn't intended to be
part of the public API.  I also not completely sure why it works, I just
know that it satisfies my integration test suite.

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

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?







On Fri, Sep 21, 2012 at 9:25 AM, Emile Joubert <emile at rabbitmq.com> wrote:

> Hi Derek,
>
> On 21/09/12 14:59, Derek Greer wrote:
> > I'm wanting to loop through all my
> > Subscription instances and call Renew() after I have a new connection.
> >  Part of the Renew() logic is to stop the current thread, and part of the
> > normal course of stopping is to attempt to close the channel/model.
>
> You shouldn't close the channel/IModel from within a shutdown callback.
> Also consider performing connection re-establishment rather than channel
> re-establishment/renewal.
>
> -Emile
>
>


-- 
___________________________________________
Derek Greer
dbgreer at gmail.com     | @derekgreer <http://twitter.com/derekgreer>
lostechies.com <http://derekgreer.lostechies.com/> |
freshbrewedcode.com<http://derekgreer.freshbrewedcode.com>
 | aspiringcraftsman.com
___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120921/e83595d1/attachment.htm>