Hi Trustin,
Well you go so fast !! I didn't download again trunk right now (but will !).
In fact, I was probably not enough precise.
Let me say it again, because I feel like I mixed two things.
I agree NewThreadExecutor was a "simple" pool of thread since it was not
(until few hours) a real pool of thread but just a new thread created each time.
Now in trunk, NioSocketConnector and NioSocketAcceptor
use SimpleIoProcessorPool when you specify no Executor or no Processor.
SimpleIoProcessorPool implies a newCachedThreadPool, in the past
it was a NewThreadExecutor.
That is what I point out in order to try to understand
(and explain to myself and perhaps to others)
why the setWorkerTimeout disapears from the trunk.
In the past, the NewThreadExecutor implies to take care of the threads
creation and deletion. Now with CachedPool, we don't have to.
Correct me of course if I am wrong...
If I am correct, probably on tip to add in the "1.x to 2.x" page...
Now on your modification, I see by looking at the snv through http
that you remove NewThreadExecutor. I hope this will be OK with
all part. I don't have any idea where this could be usefull somewhere,
so let see if the community is ok with that (I think they will).
One remark on the same subject, on the first constructor of both
NioSocketConnector and NioSocketAcceptor. I take the Acceptor
as example since Connector is the same :
- public NioSocketAcceptor()
OK, except the comment says NewThreadExecutor but it is in fact a
SimpleIoProcessorPool so a CachedPool and 1 single thread.
Looking at the code : it uses Runtime.getRuntime().availableProcessors() +
1 by default
thread in the CachedThreadPool and the same number of IoProcessor.
- public NioSocketAcceptor(int processorCount)
This one is clear at its does what it means (SimpleIoProcessorPool and
processorCount of IoProcessor).
- public NioSocketAcceptor(IoProcessor<NioSession> processor)
Same as previous except the processorCount is extract from processor and
creates an implicit SimpleIoProcessorPool.
- public NioSocketAcceptor(Executor executor, IoProcessor<NioSession> processor)
Same as previous except the processorCount is extract from processor and
the executor is the one passed as argument.
Ok, sorry for so long mails and I fell like I can be a bit ennoying,
but as it seems something to me that can affect performance a bit...
Thanks again Trustin !
Frederic
----- Original Message -----
2.0 still uses NewThreadExecutor for acceptor & connector threads, so
there's some overhead of spawning a new thread. This becomes a
problem when a user tries to request a bunch of connection with bad
timing because threads will be spawned for each request. To avoid
that situation, I programmed AbstractPollingIoConnector's Worker not
to exit until dispose() is called. However, this is waste of thread
if you explicitly specified a thread pool, as you pointed out.
The solution could be not using NewThreadExecutor but using something
different such as a cached thread pool executor. However, we are not
able to share the cached thread pool executor among all acceptors and
connectors because it means user have to call some global shutdown
method to shut down the shared thread pool. Anyways, let me fix the
problem by replacing NewThreadExecutor with
Executors.newCachedThreadPool(). :)
Thank you so much for your feed back!
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
