mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Bauroth <michael.baur...@falcom.de>
Subject Re: Is ThreadModel really useful?
Date Fri, 08 Dec 2006 07:54:52 GMT

in different tests I found out an temporary optimal solution for my 
demands. It looks like:

(using SimpleAllocator, HeapBuffer at the moment)

mAcceptor = new SocketAcceptor( 2, Executors.newCachedThreadPool() );
mAcceptor.getFilterChain().addLast( "CONNECTION_LIMITER", new 
ConnectionLimitFilter( 30000 ) );
mAcceptor.getFilterChain().addLast( "CODECS", new ProtocolCodecFilter( 
new MultiStageCodecFactory()) );
mAcceptor.getFilterChain().addLast( "THREADPOOL", new ExecutorFilter( 
Executors.newFixedThreadPool( 4 ) ) );

What does your suggestions mean for this case? Will this config still be 
available or do I have to change something?

Best Regards

Trustin Lee schrieb:
> Hi,
> MINA 1.0 provides an interesting interface called ThreadModel, which 
> extends
> IoFilterChainBuilder.  ThreadModel.buildFilterChain() is invoked after
> default build chain is built so it can insert appropriate ExecutorFilter(s)
> to apply a certain thread model.  Here's an example code that applies a
> thread model that uses one thread pool for a service:
> Executor executor = new ThreadPoolExecutor(...);
> ExecutorThreadModel model = ExecutorThreadModel.getInstance("MyService");
> model.setExecutor(executor);
> acceptor.setThreadModel(model);
> If we didn't use ThreadModel, we can manually configure the chain:
> Executor executor = new ThreadPoolExecutor(...);
> ExecutorFilter executorFilter = new ExecutorFilter(executor);
> acceptor.getFilterChain().addFirst("...", executorFilter);
> ExecutorThreadModel doesn't provide easy implementation of thread model at
> all comparing the two code snippets above, and it has a logical flaw that
> anyone can change the employed Executor implementation by calling
> setExecutor at any time.
> Then what about applying a custom thread model such as two thread pools?  A
> user will have to implement ThreadModel interface which fits to his or her
> needs, and this requires knowledge on how filter chain works, which we
> wanted to hide from users.  It actually doesn't have any difference from
> adding filters by calling acceptor.getFilterChain().add...() because the
> implementor should know which filter does what.  Creating a generic
> ThreadModel implementation is almost impossible because we don't know what
> filters a user will add to the chain.
> Besides that, ExecutorThreadModel always adds an ExecutorFilter in front of
> all filters, but we never know if this is really a good idea.  My recent
> performance test shows running protocol codec in the I/O worker threads
> makes the application perform much better.  So it totally depends on the
> characteristics of the application a user is going to implement, and
> therefore generic ThreadModel implementations don't make sense.
> To wrap up, I think ThreadModel is useless in that it adds extra complexity
> to the existing API and doesn't do anything good for us.  (Yes, I 
> introduced
> ThreadModel interface.  Argh!)  What do you think?
> Trustin

View raw message