[rabbitmq-discuss] Daemonizing connection threads (was Re: .Net client foreground threads)

Matthew Sackman matthew at lshift.net
Thu Jan 7 13:56:09 GMT 2010

On Thu, Jan 07, 2010 at 01:28:03PM +0000, Tony Garnock-Jones wrote:
> > 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?

Well, the recent ext3/4 "ZOMG closing a file doesn't sync its
content!!!eleven!!" revelations demonstrate that people will rely on
observed behaviour even if it's not guaranteed. For this reason alone, I
think that forcing people to close the connection is "the right thing"
on the grounds that the non-deterministic "you may lose messages, or you
may not" alternative leads to the ext3 situation. If things then changed
in the client to make it much more likely to lose messages in this
situation (now ext4) then people will complain. Far safer to ask users
to tidy up correctly in the first place. Yes, it may be un-Java-like,
but then again so is much good programming practice. ;)

/me throws fuel on fire and runs...


More information about the rabbitmq-discuss mailing list