Thread pooling in AIO/

[Alan Bateman]

Nord, James wrote:
> Hi all,
>  
> In testing AsyncIO we've noticed if we want to configure the thread 
> pool to use n threads we need to do 2 things.
>  
> 1) create an Executor service with Executors.newFixedThreadPool(n)
> 2) AsynchronousChannelGroup.withFixedThreadPool(executor, n)
>  
> Why do we need to provide n twice?  Shouldn't the ASyncChannel group 
> just farm off something to the exectutor service and block if needed?
Yes, this is annoying and has already been fixed for the next build, so 
you can withFixedThreadPool(nThreads, threadFactory).

>  
> The other thing is the default is awfull in our tests - as it seems to 
> create a new Thread in the pool for each AsyncDatagramChannel  (for 
> 100 multicasts received there were 130+ java threads).
Is this the default group or your own group? Also, is this 100 
outstanding receive operations on one/many channels or 100 receives (one 
after the other)? One thing to say about AsynchronousDatagramChannel is 
that it is currently just a simple implementation and isn't plumbed into 
the event port mechanism yet. This hasn't been a problem so far because 
the number of AsynchronousDatagramChannel is expected to be small. I 
assume you don't observed this with the other network channels as they 
work very differently.

>  
> Also isn't it the job of the Executor to choose chached pooled or non 
> pooled not the AsyncChannelGroup?
The default group uses a cached thread because it may be shared by 
several applications. For other groups then you supply the thread pool.

-Alan.