Thread pooling in AIO/

[Nord, James]

Hi Alan,

Comments inline.

/James 

> > 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).

But wouldn't it just be better to pass the ExecutorService then we can
do it all simply?

E.g. Executors.newFixedThreadPool(int nThreads, ThreadFactory
threadFactory)
     Executors.newXXX

> > 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. 

Sorry I missused the word "default". I was using the following:
	pool = Executors.newCachedThreadPool();
	asynchronousChannelGroup =
AsynchronousChannelGroup.withCachedThreadPool(pool, 1);

This is 100 unique sockets with one multicast group per socket.

(we are currently stressing the test with 5Mbit/s per multicast group)

However we just re ran with the actual default channel group by using
AsynchronousDatagramChannel.open()
And it creates even more threads!!

> 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.

Can you define small?  We will be targetting 100+ :-)


> > 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.

But that is my point - you have to supply the pool (via the executor)
*and also* to the AsynchronousChannelGroup.

E.g. for a fixed pool you need the following:
	ExecutorService executor = Executors.newFixedThreadPool(8);
	AsynchronousChannelGroup group =
AsynchronousChannelGroup.withFixedThreadPool(executor, 8);		

And for a cached pool you need:
	ExecutorService executor = Executors.newCachedThreadPool();
	AsynchronousChannelGroup group =
AsynchronousChannelGroup.withCachedThreadPool(executor, 4);	


Why don't we just have
	ExecutorService executor = // whatever executor type you want /
fixed cached etc...
	AsynchronousChannelGroup group =
AsynchronousChannelGroup.withThreadPool(executor);

Does the group really care if its fixed or cached - doesn't it just want
something to do some work?

/James

*********************************************************************************************************
This e-mail is confidential, the property of NDS Ltd and intended for the addressee only.  Any dissemination, copying or distribution of this message or any attachments by anyone other than the intended recipient is strictly prohibited.  If you have received this message in error, please immediately notify the postmaster at nds.com and destroy the original message.  Messages sent to and from NDS may be monitored.  NDS cannot guarantee any message delivery method is secure or error-free.  Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.  We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission.  You should carry out your own virus checks before opening any attachment.  Any views or opinions presented are solely those of the author and do not necessarily represent those of NDS.

To protect the environment please do not print this e-mail unless necessary.

NDS Limited Registered office: One Heathrow Boulevard, 286 Bath Road, West Drayton, Middlesex, UB7 0DQ, United Kingdom. A company registered in England and Wales  Registered no. 3080780   VAT no. GB 603 8808 40-00
**********************************************************************************************************