[rabbitmq-discuss] Java Client Changes

Holger Hoffstaette holger.hoffstaette at googlemail.com
Thu Oct 14 18:02:20 BST 2010

Hi Rob,

thanks for taking the time to look into this. Sorry that I haven't
commented earlier but I moved and had no internet/mail/list access etc.

On Tue, 12 Oct 2010 14:39:27 +0100, Rob Harrop wrote:

> * Dispatch to consumers now happens on a separate thread from the
> Connection thread

This is good. :)

> * Each Channel has its own dispatch thread

This is unfortunately not so good and pretty much what I was hoping to
avoid. It can lead to excessive context switching (the #1 enemy), and with
a large number of Channels to really large memory use.
I've looked at the code and understand that ChannelDispatcher will
not deadlock when a consumer calls back with Channel ops, since it runs in
the same thread. However, this is "recursive" in the sense that call
chains that are too deep could blow the stack - unlikely though.
I know that this is unavoidable since Java does not have real
continuations, but if that's the acceptable tradeoff then we might as well
just pull a Thread from an arbitrary pool, note that in the dispatcher and
do any channel ops. Any callbacks from a consumer on that thread should
now be able to re-enter the dispatcher. When all is done just clear the
current thread from the dispatcher and pop out.
That way we can have a freely configurable ExecutorService and less
threads with no deadlock on callback.

I should probably add that I just made that up and haven't tested it yet,
but maybe you find the idea interesting. :-)


More information about the rabbitmq-discuss mailing list