mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frédéric Brégier <fred.breg...@free.fr>
Subject Re: Is ThreadModel really useful?
Date Fri, 08 Dec 2006 06:59:03 GMT
Hi,
>From my experience, I use the Executors from concurrent
package (mainly newCachedThreadPool but some users
may need newFixedThreadPool), and I never use
the ThreadPoolExecutor interface directly since it is
quite complex and Executors simplify a lot the way
most of users need to handle ThreadPool.

I would suggest to make an interface to accept an
ExecutorService as input and probably to use
a default newCachedThreadPool as default in Mina.

>From what I saw, newCachedThreadPool is almost the
same as the default ThreadPool implemented in Mina
as it get a new thread for each need, except that it can reuse a previous
thread and does not need to create a new one if there are
some ine the cached Pool. I didn't make some heavy test of
performance, but the logic should say that it should be at
least the same, and probably a little bit better.

FixedThreadPool can be dangerous in context of heavy load,
but it depends on the implementation of Mina behind.
That is to say, if Mina in some part tends to shared easily
a few threads for a lot of work (therefore forking in other
threads to do the future work), perhaps a FixedThreadPool
is better in the first pool then a CachedThreadPool in second part.

So to resume, I think making the interface accepting an
ExecutorService as input should be simpler compared
to a pseudo interface between from Mina.
Of course, other users can have a different point of vue.

Frederic

----- Original Message ----- 

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
-- 
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


Mime
View raw message