Typically you would have two (or three) thread pool executors:<div><br></div><div>- One for the channel bosses (the server channel acceptors)</div><div>- One for the accepted channels (maybe the same as the first)</div><div>
- One for your task processing, after the request has been decoded and understood</div><div><br></div><div>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. </div>
<div><br></div><div>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.</div>
<div><br></div><div>Hope this helps.</div><div>Iain McGinniss</div><div><a href="http://www.onedrum.com">www.onedrum.com</a><br><br><div class="gmail_quote">On Wed, Oct 14, 2009 at 4:30 PM, phi6 <span dir="ltr"><<a href="mailto:phidinh6@gmail.com">phidinh6@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
I understand that I should use NIO, not for performance specifically but for<br>
scalability, as traditional threaded model uses up a lot of resources due to<br>
context switching.<br>
<br>
So I am using NioServerSocketChannelFactory to implement my server.<br>
<br>
So I understand, instead of thread per connection like blocking-IO, all<br>
reading and writing is done on one thread asynchronously. My question is,<br>
how does Netty (or NIO in general for that matter) handle logic that takes a<br>
long time to complete?<br>
<br>
For example, in my pipeline I have a message received handler which does<br>
some tasks based on the message it receives from clients. What if a client<br>
wants the server to do SomeLongTask() which takes about 10 seconds. If it's<br>
all on one thread, how does it manage a second connection that wants to do<br>
SomeOtherTask() before SomeLongTask() is completed? In the threaded model<br>
they would run concurrently... but with NIO there is a single thread<br>
handling all my client messages... does SomeOtherTask() get queued up until<br>
SomeLongTask() is completed?<br>
<br>
I'm probably thinking about this completely the wrong way, please advise.<br>
<br>
Many thanks<br>
<font color="#888888">--<br>
View this message in context: <a href="http://n2.nabble.com/Confused-about-Netty-NIO-tp3823513p3823513.html" target="_blank">http://n2.nabble.com/Confused-about-Netty-NIO-tp3823513p3823513.html</a><br>
Sent from the Netty User Group mailing list archive at Nabble.com.<br>
_______________________________________________<br>
netty-users mailing list<br>
<a href="mailto:netty-users@lists.jboss.org">netty-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/netty-users" target="_blank">https://lists.jboss.org/mailman/listinfo/netty-users</a><br>
</font></blockquote></div><br></div>