[rabbitmq-discuss] Fwd: .Net RabbitMQ.Client Issue: Deadlock on ConnectionShutdown
Derek Greer
dbgreer at gmail.com
Fri Sep 21 15:48:59 BST 2012
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>
More information about the rabbitmq-discuss
mailing list