<html><body bgcolor="#FFFFFF"><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); font-size: medium; "><span>On 15 Oct 2010, at 10:03, mabrek <<a href="mailto:mabrek@gmail.com" x-apple-data-detectors="true"><a href="mailto:mabrek@gmail.com">mabrek@gmail.com</a></a>> wrote:</span><br><span></span><br><blockquote type="cite"><span>On 10/12/2010 05:39 PM, Rob Harrop wrote:</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>Summary of changes:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>* Dispatch to consumers now happens on a separate thread from the Connection thread</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Have you considered switching to NIO with one io-loop thread per connection/several connections?</span><br></blockquote><blockquote type="cite"><span>Something like Netty or Apache Mina.</span><br></blockquote><span></span><br><span>We've been chewing over NIO a bit recently. It's possible that we'll switch over but currently I think 1 IO thread per connection is sufficient.</span><br><span></span><br><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>* Each Channel has its own dispatch thread</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>It can result in creating too many threads.</span><br></blockquote><span></span><br><span>This is bounded by the number of channels.</span><br><span></span><br><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>* Channels are safe for use from multiple threads (not suitable for heavy concurrent usage though)</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Consider web appication scenario. It sends a message per incoming request. Requests are served from several threads (up to 100) with a heavy concurrency (hundreds requests per second). So application needs either thread-safe non-blocking publisher that is suitable for heavy concurrency or very light-weight non-thread-safe publisher that can be created per incoming request and deleted after use.</span><br></blockquote><span></span><br><span>Channels are pretty light to create. But I can certainly see a case where thread usage can go crazy.</span></span><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); font-size: medium; "><br></span></div><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); font-size: medium; "><span></span>I'm on vacation this weekend but I'm pondering a solution to general thread pooling that will allow for a pluggable ExecutorService. The solution I have in mind will guarantee per consumer ordering and is not susceptible to stalling.</span></div><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); font-size: medium; "><br><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Regards,</span><br></blockquote><blockquote type="cite"><span>Anton Lebedevich.</span></blockquote></span></div></body></html>