You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Michael Bauroth <mi...@falcom.de> on 2006/04/21 16:16:22 UTC
Designrules for CPU intensive jobs
Hi,
just a short question. In your tutorial you describe a combination of
filters and ThreadPool for CPU intensive jobs. When I want to use time
consuming SQL operations, would it be better to locate them in the
filter / decoder part before the ThreadPoolFilter or is it equal to
handle them in the IoSession.messageReceived method (don't matter)?
Regards
Michael
Re: Designrules for CPU intensive jobs
Posted by peter royal <pr...@apache.org>.
On Apr 21, 2006, at 2:01 PM, Michael Bauroth wrote:
> Just another question. What could I do if I want to contribute to
> MINA?
> Programming? Documentation? ...
Documentation is a great way to start. As for writing code, if there
is anything you feel is lacking, dive right in and add it, otherwise
there is a list of things to be done in our jira.
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: Designrules for CPU intensive jobs
Posted by Michael Bauroth <Mi...@falcom.de>.
Ok, then I think it would be a good idea for me to read a little bit
more about the concepts behind of SEDA :)
Just another question. What could I do if I want to contribute to MINA?
Programming? Documentation? ...
Michael
Re: Designrules for CPU intensive jobs
Posted by Trustin Lee <tr...@gmail.com>.
Hi Michael,
On 4/21/06, Michael Bauroth <mi...@falcom.de> wrote:
>
> Acceptor (Processor) -> ThreadPoolFilter (now implemented in processor
> by default as BufferPool) -> CPU int. job -> ThreadPoolFilter -> IoHandler
The first thread pool filter is never different from the second one. It is
not related with the byte buffer pool we provide.
This two thread pool filter model is very similar to that of SEDA, a Staged
Event Driven Architecture. There's no best answer actually though. It is
usually OK with one thread pool filter, but I think you can use multiple
pools between the filters and handler if each has different performance
characterstics. Just doing some performance tests will help you decide.
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: Designrules for CPU intensive jobs
Posted by Michael Bauroth <mi...@falcom.de>.
Hi Pete,
peter royal wrote:
> On Apr 21, 2006, at 10:16 AM, Michael Bauroth wrote:
>
>> just a short question. In your tutorial you describe a combination of
>> filters and ThreadPool for CPU intensive jobs. When I want to use
>> time consuming SQL operations, would it be better to locate them in
>> the filter / decoder part before the ThreadPoolFilter or is it equal
>> to handle them in the IoSession.messageReceived method (don't matter)?
>
>
> You want to do them after the ThreadPoolFilter. That way they will
> occur on separate threads, and not block the thread that reads from the
> nio Selector.
>
> I'd say the general "recommended" way would be:
>
> Processor -> ThreadPoolFilter -> {custom filters} ->
> ProtocolDecoderFilter -> {custom filters} -> IoHandler
>
> .. Just do everything that could take a non-trivial amount of time
> after the ThreadPoolFilter :)
>
> -pete
>
>
In the actual tutorial I've found the following scheme:
Acceptor (Processor) -> ThreadPoolFilter (now implemented in processor
by default as BufferPool) -> CPU int. job -> ThreadPoolFilter -> IoHandler
So can (should) I forget this scheme, especially the second
ThreadPoolFilter? :)
Regards
Michael
Re: Designrules for CPU intensive jobs
Posted by peter royal <pr...@apache.org>.
On Apr 21, 2006, at 10:16 AM, Michael Bauroth wrote:
> just a short question. In your tutorial you describe a combination
> of filters and ThreadPool for CPU intensive jobs. When I want to
> use time consuming SQL operations, would it be better to locate
> them in the filter / decoder part before the ThreadPoolFilter or is
> it equal to handle them in the IoSession.messageReceived method
> (don't matter)?
You want to do them after the ThreadPoolFilter. That way they will
occur on separate threads, and not block the thread that reads from
the nio Selector.
I'd say the general "recommended" way would be:
Processor -> ThreadPoolFilter -> {custom filters} ->
ProtocolDecoderFilter -> {custom filters} -> IoHandler
.. Just do everything that could take a non-trivial amount of time
after the ThreadPoolFilter :)
-pete
--
proyal@apache.org - http://fotap.org/~osi