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

Tue Aug 21 16:38:36 BST 2012

I'm trying to deal with connection shutdown logic as an atomic operation.
 Here's the scenario I'm trying to implement:

   - An application has 25 subscriptions to different queues on different
   threads
   - The rabbitmq Windows service is restarted
   - The application detects a connection shutdown has occurred and
   performs the following actions:
      - re-establish the connection once available
      - refresh each subscription with the new connection

The problem with using ModelShutdown rather than ConnectionShutdown to
detect connectoin shutdowns (aside from the obvious reason) is that it
doesn't really allow a client to deal with connection shutdown logic
atomically.  Thinking through what I'd need to do to use ModelShutdown for
this scenario seems convoluted at best.  My particular design issues aside,
don't you agree that ConnectionShutdown should be the event you should
subscribe to when you want to know about connection shutdowns?

As far as the blocking, I'm perplexed as to why we wouldn't be seeing the
same results.  Obviously, having someone on your team be able to reproduce
the issue is key to getting it fixed.  To make sure we're actually using
the same bits, I've uploaded the project I'm testing with to
http://aspiringcraftsman.com/downloads/rabbitmq/.  If you wouldn't mind,
please try with this and see if you get the same results.  I'm assuming you
don't have the API installed into your GAC.

Derek

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

> Hi Derek,
>
> On 21/08/12 15:10, Derek Greer wrote:
> > My apologizes, I should have included the version number.  I see this
> > behavior using version 2.8.4 from NuGet.  Perhaps you're testing with a
> > different version?
>
> I tested with the latest version, but there have been no changes in that
> area since 2.8.4.
>
> > That aside, there should never be a case when a client of the
> > .Net rabbitmq client should be able to call .Close() and cause the API
> > to block indefinitely.
>
> I'm not able to reproduce the deadlock, as I said, I see an exception
> (see attached).
>
> > I appreciate your pointing me to the use of the IModel.ModelShutdown.  I
> > would have thought that event would be raised any time the model was
> > closed rather than being raised exclusively due to a connection
> > shutdown.  I'll use that if I have to, but wouldn't you agree that
> > clients of the API should be able to subscribe to the
> > IConnection.ConnectionShutdown event to be alerted to connection
> > shutdowns?
>
> Yes, ModelShutdown is raised when the channel shuts down for any reason,
> including due to a network interruption. Clients that need notification
> of the network connection shutting down should subscribe to
> ConnectionShutdown, as your example illustrates. The library also
> includes an example (RabbitMQ.Client.Examples.ExceptionTest) that shows
> how to go about this.
>
> What is the problem you are trying to solve that the alleged deadlock is
> preventing you from solving? If the problem is to ensure that channels
> are closed when connections shut down, then you don't need to do that,
> since the library already takes care of it.
>
> -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/20120821/27c84c75/attachment.htm>