Confused about Netty NIO

[phi6]

Iain McGinniss wrote:
> 
> Typically you would have two (or three) thread pool executors:
> - One for the channel bosses (the server channel acceptors)
> - One for the accepted channels (maybe the same as the first)
> - One for your task processing, after the request has been decoded and
> understood
> 
> The general idea, from what I have found in practice of using Netty so
> far,
> is that the threads given to Netty should only be used by quick,
> non-blocking code within the upstream and downstream handlers of the
> pipeline. Typically at the top of the upstream I have a handler which
> looks
> at the resultant request object (for instance, an HTTPRequest object or
> some
> other object representing a command produced by a channel handler further
> down the stack) and then dispatches this request to some other subsystem.
> I
> do this by wrapping the request in a Runnable which does the dispatch and
> pass this Runnable to an Executor.
> 
> Alternatively, if I have established some kind of contract between the
> dispatcher and the receiving subsystem that the request should be
> processed
> quickly, I just make the method call on the subsystem and let it decide
> whether it should defer execution to a separate pool or not. The first
> option is typically safer as it does not allow the programmer of the
> subsystem to accidentally stall my thread within Netty, which often has
> dire
> consequences.
> 

Thanks for that Iain, does that mean however you end up with Thread per
connection anyway (albeit indirectly) which is what I was trying to get away
from in the first place? 
-- 
View this message in context: http://n2.nabble.com/Confused-about-Netty-NIO-tp3823513p3828252.html
Sent from the Netty User Group mailing list archive at Nabble.com.