Hi,Maarten,
I think what Sterin's mean is as the referring page:
http://cwiki.apache.org/confluence/display/MINA/Configuring+Thread+Model
He maybe not undstand how the thread model configuring works. In my
perspective, if you config as this case:
ExecutorService executor = Executors.newFixedThreadPool(threadDefault);
config.getFilterChain().addLast("to-operation", new
ProtocolCodecFilter(codecFactory));
config.getFilterChain().addLast("executor", new ExecutorFilter(executor));
......
......
codec logic in your ProtocolCodecFilter implemetation will run in the I/O
processor thread ,and business logic in your IoHandler implementation will run
in other thread ,We call this thread model a ' multi-thread model'
-------------------------------------------------------------------------
Here is my answer. and I also have another question:How to add an
ExecutorFilter to an IoFilterChain ?
In some references for configuring the thread model ,one implemented code is
as follows:
IoAcceptor acceptor = ...;
DefaultIoFilterChainBuilder filterChainBuilder =
acceptor.getDefaultConfig().getFilterChain();
filterChainBuilder.addLast("threadPool", new
ExecutorFilter(Executors.newCachedThreadPool());the source link is here
:http://cwiki.apache.org/confluence/display/MINA/Configuring+Thread+Model
But in javaOne2008.pdf,in Thread Models section,
...
// One thread pool – suitable for typical servers.
//// Place CPU-bound tasks first,
//// And then thread pool.
acceptor.getFilterChain().addLast(“executor”, new ExecutorFilter(new
OrderedThreadPoolExecutor(16)));
//// Use UnorderedThreadPoolExecutor or your favorite
//// Executor instance if you don't want event ordering.
The above code difference is new
ExecutorFilter(Executors.newCachedThreadPool()) and new ExecutorFilter(new
OrderedThreadPoolExecutor(16)) ,What's the different performance between above
implements ?
BR
Allen
----- Original Message -----
From: "Maarten Bosteels" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, September 26, 2008 1:01 AM
Subject: Re: Thread model
> On Wed, Sep 24, 2008 at 4:41 AM, Ilya Sterin <[EMAIL PROTECTED]> wrote:
>> I'm using mina 1.1.6 to connect to a TCP server. Everything is
>> working, encoder/decoder and the IoHandler. I'm having an issue
>> understanding the thread model. I'm having some thoughts as to
>> whether threads are actually being spun off when IoHandler is invoked.
>> The actions we're performing are rather lite, so I used a profiler to
>> capture a few snapshots. Each one revealed only one IoHandler thread
>> being executed at a particular time.
>>
>> My configuration is as follows, I extracted only the relevant lines...
>>
>>
>> ExecutorService executor = Executors.newFixedThreadPool(threadDefault);
>> config.getFilterChain().addLast("to-operation", new
>> ProtocolCodecFilter(codecFactory));
>> config.getFilterChain().addLast("executor", new ExecutorFilter(executor));
>>
>> try {
>> acceptor.bind(instance.getAddress(), new ChainedIoHandler(handler), config);
>> }
>> catch (IOException e) {
>> e.printStackTrace();
>> }
>>
>>
>> The executor is added to the filter chain last, as per documentation
>> on the mina site, but I was also having a hard time understanding the
>> small snippet of documentation that explained the thread model usage,
>> so I'm not positive that by pushing the executor service into the
>> filter chain would make it execute each IoHandler in its own thread.
>
>
> I am using MINA 2.0 for quite some time so maybe my memories about
> MINA 1.x are not completely accurate.
>
> There's only one IoHandler, so I am not sure what you mean with
> "execute each IoHandler in its own thread." ?
> You probably mean each invocation of IoHandler.messageReceived ?
>
> Keep in mind that MINA tries to avoid the threads-per-connection
> paradigm. Instead all network events are put in a queue and processed
> by an executor. When the load is low, it's possible that all events
> are processed by the same thread, even when the executor has more
> threads available.
>
> If you want to ensure that the executor uses multiple threads: print
> out the name of the current thread inside your messageReceived
> implementation AND generate a high load on your application.
>
> regards,
> Maarten
>
>
>>
>> Thanks.
>>
