Thread contention

["이희승 (Trustin Lee)"]

Ah, I see.

Netty provides a MemoryAwareThreadPoolExecutor (MATPE) which works well
with Netty, also suppressing the task queue flood.  You could replace
the SynchronousQueue-backed ThreadPoolExecutor with MATPE to avoid the
I/O thread from being blocked.

When constructing MATPE, you might need to specify your own
ObjectSizeEstimator implementation instead of the default one.  Please
refer to the source code of DefaultObjectSizeEstimator to see how it works.

HTH,
Trustin

On 06/17/2010 10:10 PM, mrochon wrote:
> 
> Hi Trustin, thanks for your response,
> 
> The problem I am seeing is as such:
> 
> I construct my worker thread pool with the following code:
> 
> [code]
>      new ThreadPoolExecutor(MIN_POOL_SIZE, poolSize, idleTimeout,
> TimeUnit.SECONDS, (BlockingQueue)(new
> ArrayBlockingQueue<Runnable>(maxQueuedTasks)));
> [/code]
> 
> With:
> MIN_POOL_SIZE=1
> poolSize=50
> idleTimeout=60
> maxQueuedTasks=50000
> 
> 
> The problem is, as soon as my number of connections reaches MIN_POOL_SIZE
> connections will block until the queue fills up, before creating new
> threads.
> 
> If I close the (1=MIN_POOL_SIZE) working connection, the next one starts
> working, as if the thread was bound to the connection.
> 
> With a synchronous queue, the threads are active but able to serve multiple
> connections. I'm not sure what I am doing wrong.
> 
> I understand that the executor will prefer to queue a task rather than
> create a new thread, and maxQueuedTasks is just an initial parameter to be
> tuned. But I would expect the active threads to be executing the queued
> tasks instead of blocking until the connection closes.

-- 
what we call human nature in actuality is human habit
http://gleamynode.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 293 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20100617/ced52c6e/attachment.bin