Oups ! I hope my last answears on the same kind of subject was not too buggy... (see [MINA 1.x] IoThreadPoolFilter & ProtocolThreadPoolFilter).
So if I try to make a resume (I love this word since it is in my mother tongue) : 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 ?) Second, no need to use ThreadModel.MANUAL. Third, inserting a threadpool filter is useless if set before. OK. One more question to set a more accurate Executor: 1) The ExecutorThreadModel API says : "public void setExecutor(Executor executor) Changes the underlying Executor of this model. Previous settings such as the number of threads should be configured again. Only newly created IoSessions will be affected." 2) Also the default ExecutorFilter inserted by Mina uses 16 threads but there is a constructor with an Executor as parameter. I try to read from API or code, but I must admit that I was not able to fully understand how to set up my own ThreadModel. My 2 cents would be to define it through ExecutorThreadModel.setExecutor, but is this correct ? To add some information on my project : For the moment, I am not ready to test my project on big servers, but I should be able to do so in about 6 months on a 16 to 32 processors server (Power5 AIX5.3). The project is about something like a file server with about 2^64 files and 200 000 users. I check every day the mailing list to find how people say they improve their performance in order to do some right choice already from now. I saw the heap buffer, another mail on thread performance, and of course on JDK 1.5. I look in the code of Mina and saw a lot of "synchronized" that many benchmarks (outside Mina) report this is less efficient than native concurrent version. I know that Mina start from 1.4, so I understand clearly the reasons why. I saw a lot of HashMap that should be easily changed to ConcurrentHashMap, removing the unecessary synchronized and using backport in the mean time for people not in JDK 1.5. If I had some time, I will try on a copy of Mina to see if it works and how. Also, the main BlockingQueue in mina.util, even if it is not so simple, coule be changed to a ConcurrentLinkedQueue or so (I try and it was not working with some exception but no time to investigate further). As many other people : Thank a lot for your job since I would not be able to create my project from scratch without Mina ! Frederic ----- Original Message ----- Subject: Re: ThreadPool in Mina with concurrent from Java5 Howto ? Hi Frederic, On 9/26/06, Frédéric Brégier <[EMAIL PROTECTED]> wrote: > > Sorry to come back on this subject, but I am a bit > confused with the Mina logic for ThreadPool. > > First, what I suppose to understand : > - First IoAcceptor have one ThreadPool to handle > incoming IoSessions. > - Second, the IoConfig use a ThreadPool to handle > process of filters. > - Eventually, in the filter chain, we can insert a new ThreadPool > for specific filters that are supposed to consume a lot of cpu > (for example compression or ssl ?). > > For me, the doc says there are two level of ThreadPool management, > but in the API I found three levels. Do I missed something ? The documentation is outdated seriously. First, there's no such level in MINA. In MINA 0.8, we had two layers, but they are merged into one layer, and there's only one filter chain per session. The thread model is decided by the number of ExecutorFilter you inserted into the chain. By default, one ExecutorFilter is inserted, but you can change this behavior by setting a different ThreadModel. Please refer to ThreadModel JavaDoc and its subclasses. 1) Put a fixed threadPool to IoAcceptor : let me known if someone > can say if it is better here to use a CachedThreadPool or a > FixedThreadPool > ? > It highly depends I woul say how Mina is using it. > > IoAcceptor acceptor = new SocketAcceptor(nbThread, executor1); You usually don't need to specify the executor as a constructor parameter. It's for some containers or microkernels which want to manage threading. 2) Put a cached threadPool in IoAcceptorConfig : > I don't know here if it is the same than (1) or not ? > When I look into the code of Mina, it seems not, > but I am really not sure. (1) and (2) are very different as I answered above. IoAccaptorConfig config = new SocketAcceptorConfig(); > config.setThreadModel(executor2); > > Also I don't understand why Peter (and in the old doc) > I should use : > IoConfig.setThreadModel( ThreadModel.MANUAL ); You can use ThreadModel.MANUAL if you want, but then you have to insert ExecutorFilter by yourself. The default thread model is a PooledThreadModel. ThreadModel extends IoFilterChainBuilder, and inserts an appropriate thread pool filter into the filter chain when a session is created. So, if you set the right ThreadModel, you don't need to insert another thread pool filter by yourself. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
