Hi,
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.setThreadModel(ThreadModel.MANUAL);
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
Michael
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
