hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: HttpCore NIO and concurrent session count control
Date Wed, 26 Sep 2012 12:17:52 GMT
On Wed, 2012-09-26 at 13:47 +0400, Dmitry Potapov wrote:
> Oleg,
> Thank you for quick response.
> Unbounded thread pool is not acceptable for me, but there is also no
> need to process an arbitrary number of concurrent requests. It is ok
> for me to not accept new connections until some worker become idle.
> So, threads count in the pool can be limited by number of concurrent
> connections, without having any restrictions in the thread pool
> itself.
> So, my first idea is to override
> DefaultListeningIOReactor.addChannel() which will block if current
> connections count is above than some config-defined value until some
> existing connection close. Having maximum connections count set to the
> half of the desired maximum workers count I'll avoid any blocking
> inside request handler. 

This sounds quite reasonable. One can safely block the listener thread
without affecting already established I/O sessions. You could even try
suspending those channels you are not able to process instead of
blocking the thread, thus allowing the server to continue accepting
incoming connection requests even if it is currently unable to handle

> As far as I understand it, channels have
> one-to-one correspondence with connections, please, correct me, if it
> the are not.

This is correct. Socket / Channel / IOSession instances all effectively
represent a single connection, albeit at different levels.

> It seems to me that this will work fine. Please, let me know if I
> missed something.
> I have two other thoughts concerning thread count limitation.
> 1. Implement IOReactor same as AbstractMultiworkerIOReactor but with
> limited thread pool instead of «Thread[] threads;». So,
> AbstractMultiworkerIOReactor.addChannel() will try to put new
> Worker(channel, dispatcher, eventDispatch), which will serve single
> channel, or block, if there is no idle threads. In this case,
> HttpAsyncRequestHandler<HttpRequest>.handle() will never be called
> concurrently with corresponding
> HttpAsyncResponseProducer.produceContent(). Just because they will be
> called in series.
> 2. Implement IOReactor same as AbstractMultiworkerIOReactor but with
> worker threads splitted into four separate groups, one for each
> possible operation from SelectionKey. So,
> HttpAsyncRequestHandler<HttpRequest>.handle() blocked on putting task
> in thread pool won't prevent worker threads from OP_WRITE group from
> executing their task. Corresponding channels will be moved from one
> workers group to another basing on some event, like
> HttpAsyncExchange.submitResponse().
> Please, let me know, if any of these two approaches has significant
> advantages over DefaultListeningIOReactor.addChannel() overloading.

Sounds scaringly complex to me. Truth to be told I have never considered
the idea of moving I/O sessions around between different threads. I may
be wrong there but I would recommend using a queuing mechanism of some
sort instead.


To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message