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

Derek Greer dbgreer at gmail.com
Fri Sep 21 14:59:49 BST 2012


I just realized I sent this response directly to Emile instead of back to
the list, so copying the list now.

---------- Forwarded message ----------
From: Derek Greer <dbgreer at gmail.com>
Date: Tue, Aug 21, 2012 at 11:21 AM
Subject: Re: [rabbitmq-discuss] .Net RabbitMQ.Client Issue: Deadlock on
ConnectionShutdown
To: Emile Joubert <emile at rabbitmq.com>


Thanks for the example.  I'll take a look at how its being done there.

Concerning subscriptions, I'm referring to a logical subscription not any
particular component of the rabbitmq API.  I have a Subscription class that
represents a logical subscription which contains a Renew(IConnection
connection) method which stops the current thread and restarts it with the
newly available connection.  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.


On Tue, Aug 21, 2012 at 11:13 AM, Emile Joubert <emile at rabbitmq.com> wrote:

> Hi Derek,
>
> On 21/08/12 16:38, Derek Greer wrote:
> > I'm trying to deal with connection shutdown logic as an atomic
> > operation.  Here's the scenario I'm trying to implement:
>
> I hesitate to mention it, because this library has been deprecated but
> not yet completely removed:
> http://hg.rabbitmq.com/rabbitmq-dotnet-messagepatterns/
>
> In it you will find an example of how one might go about reconnecting to
> a broker. Be warned that this code will be removed soon and is not
> guaranteed to work with recent versions of the broker.
>
> >       o refresh each subscription with the new connection
>
> 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.
>
> > aside, don't you agree that ConnectionShutdown should be the event you
> > should subscribe to when you want to know about connection shutdowns?
>
> Yes.
>
> > As far as the blocking, I'm perplexed as to why we wouldn't be seeing
> > the same results.
>
> When I run your Consumer.exe  standalone I also get the same exception
> as before.
>
>
>
> -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
___________________________________________





-- 
___________________________________________
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/7a6a5797/attachment.htm>


More information about the rabbitmq-discuss mailing list