[rabbitmq-discuss] .Net client foreground threads

[Matthew Sackman]

Hi Jeremy,

On Wed, Jan 06, 2010 at 11:36:43AM +0000, Matthew Sackman wrote:
> On Tue, Dec 29, 2009 at 06:39:28PM -0600, Jeremy Dunck wrote:
> > Is there a reason for the main loop and heartbeat threads to be
> > Foreground threads?  I was expecting my process to die when my last
> > app thread died, but the Rabbit threads are Foreground (the default)
> > so they keep the process alive.
> 
> Yes, we agree, the standard patterns of use for C# and Java suggest that
> these threads should be background/daemon. We have a bug open to cover
> this for the Java client, and I've added a not to it so that it covers
> the C# thread too.
> 
> Although this may sound a bit like doing manual memory-management, it is
> probably a good idea to think about how could could manually shutdown
> the AMQP connection. That way you will get some guarantees about
> messages which are sitting in buffers actually being flushed out (if you
> just terminate abruptly, you /could/ lose publishes that have not made
> it to the OS TCP buffers yet).

It would appear I can't read our own bugs. The conclusion of the bug is
that we should not set the threads in the Java or .Net clients as
daemon/background precisely because of the risk of losing messages. The
connection should always be explicitly closed. Furthermore, this offers
fewer surprises - if you find the application's hanging around too long
you know you've got connections left open. The alternative is that you
sometimes see messages disappear without trace which is far worse, and
much harder to debug.

My apologies for misleading you.

Matthew