[rabbitmq-discuss] Daemonizing connection threads (was Re: .Net client foreground threads)
tonyg at lshift.net
Thu Jan 7 13:28:03 GMT 2010
Matthew Sackman wrote:
> 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.
Well, that's where discussion is *resting* at the moment :-) I am
personally of the opinion that the threads *should* be set daemon, on
the theory that not closing an AMQP connection before exiting is like
not flushing a buffer wrapping a socket stream before exiting. Both
result in (potentially) losing data; neither is automatically taken care
of for you by the infrastructure. In the case of sockets, the VM is
happy to exit and force the socket shut without flushing buffers; I
think AMQP should behave in the same way.
> The connection should always be explicitly closed.
I agree with this (just like I'd agree with "you should always flush
your buffers before exiting"), since it's the only way to be sure that
traffic you intended to send actually got sent.
> The alternative is that you
> sometimes see messages disappear without trace which is far worse, and
> much harder to debug.
Well that's true. Perhaps the non-auto-buffer-flushing behaviour around
sockets is simply (yet another instance of) premature optimisation from
the Java library designers?
 Tony Garnock-Jones | Mob: +44 (0)7905 974 211
 LShift Ltd | Tel: +44 (0)20 7729 7060
  http://www.lshift.net/ | Email: tonyg at lshift.net
More information about the rabbitmq-discuss