You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Trustin Lee <tr...@gmail.com> on 2006/12/08 06:45:01 UTC
Is ThreadModel really useful?
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
Re: Is ThreadModel really useful?
Posted by Frédéric Brégier <fr...@free.fr>.
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
Re: Is ThreadModel really useful?
Posted by Trustin Lee <tr...@gmail.com>.
On 12/8/06, Michael Bauroth <mi...@falcom.de> wrote:
>
> 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?
If we remove ThreadModel interface, removing the second line (
mAcceptor.setThreadModel(...)) will suffice. That's all.
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
Re: Is ThreadModel really useful?
Posted by Michael Bauroth <mi...@falcom.de>.
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
Re: Is ThreadModel really useful?
Posted by Niklas Therning <ni...@trillian.se>.
peter royal wrote:
> On Dec 7, 2006, at 9:45 PM, Trustin Lee wrote:
>> 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?
>
> +1 on removing it.
>
> I don't use it, and personally recommend that people do a manual
> ThreadModel anyways :)
We're setting up our ExecutorFilter manually too. I also think the
ThreadModel could actually be confusing to new users. So
+1 from me too.
/Niklas
Re: Is ThreadModel really useful?
Posted by peter royal <pr...@apache.org>.
On Dec 7, 2006, at 9:45 PM, Trustin Lee wrote:
> 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?
+1 on removing it.
I don't use it, and personally recommend that people do a manual
ThreadModel anyways :)
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: Is ThreadModel really useful?
Posted by Yeroc <cp...@gmail.com>.
Trustin Lee wrote:
>
> 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?
>
Agreed, as a new user of the Mina API the multiple ways of setting up
threading just adds confusion. Using the Filter interfaces makes sense,
especially using the Java 5-standard Executor/ExecutorService APIs.
My 2 cents.
Corey
--
View this message in context: http://www.nabble.com/Is-ThreadModel-really-useful--tf2778892.html#a7797881
Sent from the mina dev mailing list archive at Nabble.com.