Confused about Netty NIO

Iain McGinniss iainmcgin at gmail.com
Thu Oct 15 06:12:30 EDT 2009


On Thu, Oct 15, 2009 at 10:40 AM, phi6 <phidinh6 at gmail.com> wrote:

>
> 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?
>

By leaving Netty to decide how to use the thread pools you provide, and
using a separate pool for processing requests, Netty will not need to create
more threads than are required to handle the load of the open channels.
Typically, this will be less than 1 thread per connection.

The thread pool used to process the requests can be any size you like, and
it is decoupled from the activity on the channels themselves. Take a look at

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ThreadPoolExecutor.html
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/Executors.html

for more information on the options available in creating a thread pool
executor. The strategy here is to prevent long-running tasks (or blocking
behaviour) from stalling Netty's event-driven architecture, while also
giving you control over how many threads are used in processing the
requests, once they have been decoded from the wire. If in doubt, a cached
thread pool executor is a good choice, until you can get more information
from profiling to guide better choices (which would typically be system and
architecture specific, so be wary of over-optimising).

Iain
www.onedrum.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20091015/bb2de0f7/attachment.html 


More information about the netty-users mailing list