Just 2 little questions

[Michael Bauroth <Mi...@falcom.de>]

Hi,

1. has somebody maybe a little graphical sketch about the logical 
structure and the responsibilities of the single components within the 
Mina queue? I know there is one document, which describes the data flow, 
but I'm missing the key, which parts are (maybe) concurrent and which 
parts are serial (one thread). What I'm searching for (because I'm a 
little bit confused about it at the moment) is the following:

- acceptors: Do they split into more than one thread? I think so, right? 
Where I can adjust the parameters for this behaviour?

- filterchain / codecs: Is there more than one concurrent chain? Depends 
from acceptor threads, right? Is it right, that I can't use lesser 
chains than acceptor threads? Can I add more chains by adding a 
ThreadPoolFilter at the beginning?

- sessionhandler: How many sessionhandlers exist per default? One or as 
many as filterchains? Can I modify this?

It would be really great(!) not only for newbies to have such an sketch 
to go sometimes back and remember, how all works together.



2. I've implemented my current application in the normal way, that the 
codecs decode the data and forward them to the sessionhandler, where 
they are handled. Now I'm wondering, if it would also be possible (and 
clean from the view of Mina) to handle the decoded data already in the 
codecs itself without forwarding them to the sessionhandler. Would I get 
a performance impact in this case?


I hope that somebody has a little bit time to answer my questions.

Best Regards
Michael

Re: Just 2 little questions

[向秦贤 <fy...@gmail.com>]

Hi,
Agree mat. You need what?
If and just if from face of "I want more" IoHandler,
You can create YourIoHandler which contains more IoHandlers It's OK.
Mina know YourIoHandler and Only need that like IoHandler,
but not know other contained IoHandlers.

What do you want?
bush? or ladon? or peace?
:)) Its a JOKE

Regards

2007/6/28, Michael Bauroth <mi...@falcom.de>:
>
> Thank you for your answers. That was what I looked for. The only
> remaining question: So default there exist one single IoHandler. If I
> want more (i.e. one per session) I must configure this. Right?
>
> Best Regards
> Michael
>
>


-- 
向秦贤

Re: Just 2 little questions

[Trustin Lee <tr...@gmail.com>]

On 6/28/07, Michael Bauroth <mi...@falcom.de> wrote:
> Thank you for your answers. That was what I looked for. The only
> remaining question: So default there exist one single IoHandler. If I
> want more (i.e. one per session) I must configure this. Right?

Exactly.  multiton package is particularly useful when you need to
stor many attributes in the session.  Instead of using many down-casts
and getAttribute() calls, you can simply access member variables,
which is very convenient.

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: Just 2 little questions

[Michael Bauroth <mi...@falcom.de>]

mat schrieb:
> Why you needs that?

I don't need more. I only want to be sure, that the IoHandler is 
something like a single point / concentrator in my message queue.

Regards
Michael

Re: Just 2 little questions

[mat <fo...@gmail.com>]

Why you needs that?

On 6/28/07, Michael Bauroth <mi...@falcom.de> wrote:
>
> Thank you for your answers. That was what I looked for. The only
> remaining question: So default there exist one single IoHandler. If I
> want more (i.e. one per session) I must configure this. Right?
>
> Best Regards
> Michael
>
>

Re: Just 2 little questions

[Michael Bauroth <mi...@falcom.de>]

Thank you for your answers. That was what I looked for. The only 
remaining question: So default there exist one single IoHandler. If I 
want more (i.e. one per session) I must configure this. Right?

Best Regards
Michael

Re: Just 2 little questions

[Mark Webb <el...@gmail.com>]

check out this link to the presentation Peter Royal gave at ApacheCon this
year

http://people.apache.org/~proyal/MINA%20AC%20EU%202007.pdf

On 6/27/07, Trustin Lee <tr...@gmail.com> wrote:
>
> Hi Michael,
>
> On 6/28/07, Michael Bauroth <Mi...@falcom.de> wrote:
> > Hi,
> >
> > 1. has somebody maybe a little graphical sketch about the logical
> > structure and the responsibilities of the single components within the
> > Mina queue? I know there is one document, which describes the data flow,
> > but I'm missing the key, which parts are (maybe) concurrent and which
> > parts are serial (one thread). What I'm searching for (because I'm a
> > little bit confused about it at the moment) is the following:
> >
> > - acceptors: Do they split into more than one thread? I think so, right?
> > Where I can adjust the parameters for this behaviour?
>
> You could find the information here:
> http://mina.apache.org/configuring-thread-model.html
>
> > - filterchain / codecs: Is there more than one concurrent chain? Depends
> > from acceptor threads, right? Is it right, that I can't use lesser
> > chains than acceptor threads? Can I add more chains by adding a
> > ThreadPoolFilter at the beginning?
>
> There's one chain per session.  It doesn't relate to acceptor or the
> number of threads.
>
> > - sessionhandler: How many sessionhandlers exist per default? One or as
> > many as filterchains? Can I modify this?
>
> One handler instance serves more than one sessions.  If you want each
> session to have its own handler, please take a look into
> org.apache.mina.handler.multiton.
>
> > It would be really great(!) not only for newbies to have such an sketch
> > to go sometimes back and remember, how all works together.
>
> I agree with you.  We need to add more information to our documentation.
>
> > 2. I've implemented my current application in the normal way, that the
> > codecs decode the data and forward them to the sessionhandler, where
> > they are handled. Now I'm wondering, if it would also be possible (and
> > clean from the view of Mina) to handle the decoded data already in the
> > codecs itself without forwarding them to the sessionhandler. Would I get
> > a performance impact in this case?
>
> It depends on where your codec filter is placed in the filter chain
> and on what you do with the decoded data.  If the filter is placed
> before executor filter, it will run in the I/O processor thread, and
> therefore the performance can be impacted if what you do with the
> decoded data is a time-consuming task.  If it's just a task that takes
> up some CPU and finishes fast, it's OK.
>
> HTH,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>



-- 
..Cheers
Mark

Re: Just 2 little questions

[Trustin Lee <tr...@gmail.com>]

Hi Michael,

On 6/28/07, Michael Bauroth <Mi...@falcom.de> wrote:
> Hi,
>
> 1. has somebody maybe a little graphical sketch about the logical
> structure and the responsibilities of the single components within the
> Mina queue? I know there is one document, which describes the data flow,
> but I'm missing the key, which parts are (maybe) concurrent and which
> parts are serial (one thread). What I'm searching for (because I'm a
> little bit confused about it at the moment) is the following:
>
> - acceptors: Do they split into more than one thread? I think so, right?
> Where I can adjust the parameters for this behaviour?

You could find the information here:
http://mina.apache.org/configuring-thread-model.html

> - filterchain / codecs: Is there more than one concurrent chain? Depends
> from acceptor threads, right? Is it right, that I can't use lesser
> chains than acceptor threads? Can I add more chains by adding a
> ThreadPoolFilter at the beginning?

There's one chain per session.  It doesn't relate to acceptor or the
number of threads.

> - sessionhandler: How many sessionhandlers exist per default? One or as
> many as filterchains? Can I modify this?

One handler instance serves more than one sessions.  If you want each
session to have its own handler, please take a look into
org.apache.mina.handler.multiton.

> It would be really great(!) not only for newbies to have such an sketch
> to go sometimes back and remember, how all works together.

I agree with you.  We need to add more information to our documentation.

> 2. I've implemented my current application in the normal way, that the
> codecs decode the data and forward them to the sessionhandler, where
> they are handled. Now I'm wondering, if it would also be possible (and
> clean from the view of Mina) to handle the decoded data already in the
> codecs itself without forwarding them to the sessionhandler. Would I get
> a performance impact in this case?

It depends on where your codec filter is placed in the filter chain
and on what you do with the decoded data.  If the filter is placed
before executor filter, it will run in the I/O processor thread, and
therefore the performance can be impacted if what you do with the
decoded data is a time-consuming task.  If it's just a task that takes
up some CPU and finishes fast, it's OK.

HTH,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6