I will try to answear you, as much as I can, of course ;-)
If I am going wrong, I hope the Mina team will correct me.

Mina has 2 levels of thread pool :
- First is for IoAcceptor, relative to the incomming connections.
    By default, Mina is setting 16 threads for this level.
- Second is for FilterChain where business logic takes place.
    It is used, once the connexion is established to take care
    of incoming messages (not connection, only messages).
    By default, Mina is setting 16 threads too for this level (not sure).

For most of the applications, this should be ok. My current project
is probably needing more thread and more control, that's why I
was interested like you how to manage them.

Then, what I wrote is if you want to take care for some reasons
of how these two levels of threadpools are used and their size.
So, now on your question :

> For SocketAcceptor (or IoAcceptor) :
>     Executor executor1 = Executors.newFixedThreadPool(nbThread);
>     SocketAcceptor acceptor = new SocketAcceptor(nbThread, executor1);
>
1) Is there any relationship between "Number of processing threads" (in 
constructor of SocketAccepter) and "thread-pool's size" (in function 
newFixedThreadPool)? In your example, they would be the same, right?

As I wrote :
> My feeling is that it shouldn't be a newCachedThreadPool here since
> it seems it is relative to the number of SocketIoProcessors that
> the SocketAcceptor will use.
> By default (new SocketAcceptor() without arguments), it use
> a value of 16 threads and SocketIoProcessors.
That is to say, as far as I understand Mina code, the number of thread
in the ThreadPool should be relative to the specified number (nbThread).
This number says how many SocketIoProcessors will
be used (used to manage network level).
So yes, the number should be the same, at least from what I know.

> For SocketAcceptorConfig (or IoAcceptorConfig), in order to
> be able to specify my own Thread Pool Filter:
>     SockectAccaptorConfig config = new SocketAcceptorConfig();
>     config.setThreadModel(ThreadModel.MANUAL);
2) If I set the fixed number of threads, do I need to set the ThreadModel 
for the SocketAcceptorConfig as your direction?
I think that when we set the MANUAL model, that means we created the 
thread-pools ourselves, no need the MINA to take care? Please advice me.

You still have the "nbThread" in the first part of Mina
(or 16 threads by default if you use simply new SocketAcceptor() ),
whatever you specify ThreadModel.MANUAL or not.
This call is not for the SocketIoProcessors control, but for the
FilterChain where the business logic comes into Mina.
Specifying ThreadModel.MANUAL change the default
behaviour (16 threads ?) to be set as Manual, that is to say
1 thread only. So if you use it, you HAVE to specify a threadpool
in your business logic in the filter chain, except if you
don't need at all threads for this part (for instance if your
business logic is so simple that it will take more time
to start a new thread that to do the work).
If you don't specify the ThreadModel.MANUAL,
then the default behaviour of Mina takes place with
another level of threads for FilterChain.

So specifying later on some newCachedThreadPool in the
FilterChain will add thread pool in your business logic.


3) From MINA 1.x, there is only one thread-pool is used instead of 
"IoThreadPoolFilter & ProtocolThreadPoolFilter" (mina 0.8.x), right? I need 
to be clarify because I am migrating my software from 0.8.x to 1.0 but in 
the past it used 2 configured parameters to set thread-pool's size. Please 
help me too. Thanks.
I don't understand much about the "filter chain"... or something related, I 
hope I could take time to investigate this function of MINA soon. Hope they 
are not so hard to learn.
Thanks & best regards,
Hieu Phan.

I was not using Mina 0.8.
In Mina 1.0, there are two levels of thread pool :
- IoThreadPoolFilter is relative to the first level (now in IoAcceptor) for 
connection.
- ProtocolThreadPoolFilter should be relative to the second level 
(ProtocolHandler
    should be relative to FilterChain as far as I understand from the api 
0.8 except
    the logic of Mina > 0.9 seems to change a bit in this part).
I suggest you to look at example in Mina to understand the FilterChain 
example
(specially the SumUp example).

Hoping this will help you !
Frederic 

Reply via email to