Julien (and others of course),
>On dit "mother language" en anglais, "tongue" c'est pour l'organe,
>Attention au sens de ta phrase ;)
Comme quoi, tous les dictionnaires ne sont pas bons !
(ma source = Dictionnaire Hachette Oxford électronique ;-(
>> First, we don't need to specify any thread pool in:
>> IoAcceptor acceptor = new SocketAcceptor();
>> (but here we have 16 threads by default, and if we have > 16 processors
>> ?)
>Exactly default Executor is :
>new ThreadPoolExecutor(16, 16, 60, TimeUnit.SECONDS, new
>LinkedBlockingQueue() )
So, perhaps should we do something like testing
the number of CPU and then create at least 16 threads,
or at most the number of real cpu in the SocketAcceptor code ?
>I think so, try instantiations like "new ThreadPoolExecutor(16, 16, 60,
>TimeUnit.SECONDS, new LinkedBlockingQueue() )", tuning size of the pool
>(first '16') and max pool size (the second '16' value).
For the moment, I just try on "small" servers (2 cpu), so I cannot
really see the difference.
To do as you suggest, I do the following :
Executor executor = Executors.nexFixedThreadPool(nb);
IoAcceptor acceptor = new SocketAcceptor();
ExecutorThreadModel execmodel = (ExecutorThreadModel)
acceptor.getDefaultConfig().getThreadModel();
execmodel.setExecutor(executor);
And I remove any reference to any other thread pool in my code.
It seems to be almost the same right now than before.
Of course I need to recheck.
Is my way ok ?
But I note that if I call SocketAcceptor() without arguments,
then only 1 SocketIoProcessor is created (with 1 thread).
So is my model OK or should I specify also a threadpool
for SocketAcceptor ?
OK, OK, I agree, I insist, but I make some progress ;-)
>Sound very interesting feedback on MINA behaviour on this configuration.
Of course, I will...
>Sure, with integration of the j.u.concurrent backport dependency we have
>a new space of optimization for MINA, but it's a pretty young
>integration.
I agree, and some of them should be not so difficult.
Frederic
