You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Horace Pinker <fl...@yahoo.com> on 2006/09/13 13:59:12 UTC

[mina] Re: mina 0.9.4 - io/business logic decoupling with threads

hi trustin,

i now setup the acceptor as described in your post:

            SocketAcceptorConfig cfg = new SocketAcceptorConfig();
            cfg.setThreadModel(ThreadModel.MANUAL);

            DefaultIoFilterChainBuilder chain = cfg.getFilterChain();

            ThreadPoolFilter firstPool = new ThreadPoolFilter();
            firstPool.setMaximumPoolSize(32);
            chain.addLast("firstpool", firstPool);

            chain.addLast("codec", new ProtocolCodecFilter(new TextLineCodecFactory()));

            ThreadPoolFilter secondPool = new ThreadPoolFilter();
            secondPool.setMaximumPoolSize(32);
            chain.addLast("secondpool", secondPool);
            
            Acceptor = new SocketAcceptor();
            Acceptor.bind(new InetSocketAddress(IP, Port), new NET_SessionHandler(this), cfg);

i had to remove some code from sessionCreated:

    public void sessionCreated(IoSession _IOSession)
    {
        ...
        
        TextLineCodecFactory codec = new TextLineCodecFactory();
        codec.setDecoderMaxLineLength(1024);
        
        ...

        _IOSession.getFilterChain().addFirst("protocolFilter", new ProtocolCodecFilter(codec));
        
        ...
    }

i assume the chain is now setup like this because of the cfg i provided when i bound the acceptor?

in general i prefer the way it is now, because i did not like the code in the sessionCreated function anyhow :D

some questions regarding the 2 pools:

1stpool:

- by default (without a custom pool setup) only this pool would exist?

- if only this pool exists it will be used to execute io->filter AND filter->handler?

- is is guaranteed that filter->handler for a specific connection is called SEQUENTIALLY which would in my case guarantee that ONE and ONLY ONE textline of a specific connection is forwarded to my handler?

2ndpool:

-  if this is available the 1st pool will only exectute io->filter while this 2nd pool 
with only execute filter->handler?

- i assume this 2nd pool would be beneficial if business logic (in the handlers) may be expensive (jdbc stuff i.e.), because with one pool this bl would block the filters? if this is the case, would the io (sending/receiving) be blocked, too?

thanks!

cheers,
horace

Trustin Lee <tr...@gmail.com> wrote: Hi Horace,

On 9/1/06, Horace Pinker  wrote:
>
> i'm using mina 0.9.4.


We will release 0.9.5 soon, I think you'd better upgrade soon because
0.9.5contains a *lot* of fixes.

this is how i set up the acceptor:
>
> Acceptor = new SocketAcceptor();
> Acceptor.bind(new InetSocketAddress(Port), new NET_SessionHandler(this));


Looks good.

i read the docs and found some info regarding ThreadModel, however this info
> seems to be outdated for 0.9.4.


I am sorry about that.  Please let us know any JavaDoc which is outdated.
We need to fix it.

is by default iologic and businesslogic decoupled and in separate
> threadpools in mina 0.9.4?


We need to clarify things a little bit here.  Basically there are three
parties when you program a network application:

* I/O code - MINA transport implementation (e.g. SocketAcceptor)
* Protocol encoder and decoder - ProtocolCodecFilter in MINA
* Business logic - IoHandler in MINA

By default, a thread pool is inserted between the I/O code and the protocol
codec.  You can also insert another thread pool between the codec and the
business logic, but you have to insert it manually.

To insert the second thread pool:

SocketAcceptorConfig cfg = new SocketAcceptorConfig();

// Set the thread model to 'manual'
cfg.setThreadModel(ThreadModel.MANUAL);

DefaultIoFilterChainBuilder chain = cfg.getFilterChain();

// Add the first thread pool
ThreadPoolFilter firstPool = new ThreadPoolFilter();
firstPool.getThreadPool().setMaximumPoolSize(32); // max # of threads
chain.addLast("firstpool", firstPool);

// Add the codec
chain.addLast("codec", new ProtocolCodecFilter(...));

// Add the second thread pool
ThreadPoolFilter secondPool = new ThreadPoolFilter();
...
chain.addLast("secondpool", secondPool);

Otherwise, you could create your own ThreadModel implementation that inserts
thread pools as you want:

public class MyThreadModel implements ThreadModel {

    public void buildChain(IoSession session) {
        IoFilterChain chain = session.getFilterChain();
        chain.addFirst("pool", new ThreadPoolFilter(...));
        // insert the second thread pool next to the codec.
        chain.addAfter("codec", "pool-2", new ThreadPoolFilter(...));
    }
}

I think the second example is much cleaner and separates the responsibility
of classes properly.  Its weakness is that you have to assume the name of
the codec filter.

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


 		
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at 1ยข/min.

Re: [mina] Re: mina 0.9.4 - io/business logic decoupling with threads

Posted by Trustin Lee <tr...@gmail.com>.
Hi Horace,

On 9/13/06, Horace Pinker <fl...@yahoo.com> wrote:
>
> hi trustin,
>
> i now setup the acceptor as described in your post:
>
>             SocketAcceptorConfig cfg = new SocketAcceptorConfig();
>             cfg.setThreadModel(ThreadModel.MANUAL);
>
>             DefaultIoFilterChainBuilder chain = cfg.getFilterChain();
>
>             ThreadPoolFilter firstPool = new ThreadPoolFilter();
>             firstPool.setMaximumPoolSize(32);
>             chain.addLast("firstpool", firstPool);
>
>             chain.addLast("codec", new ProtocolCodecFilter(new
> TextLineCodecFactory()));
>
>             ThreadPoolFilter secondPool = new ThreadPoolFilter();
>             secondPool.setMaximumPoolSize(32);
>             chain.addLast("secondpool", secondPool);
>
>             Acceptor = new SocketAcceptor();
>             Acceptor.bind(new InetSocketAddress(IP, Port), new
> NET_SessionHandler(this), cfg);
>
> i had to remove some code from sessionCreated:
>
>     public void sessionCreated(IoSession _IOSession)
>     {
>         ...
>
>         TextLineCodecFactory codec = new TextLineCodecFactory();
>         codec.setDecoderMaxLineLength(1024);
>
>         ...
>
>         _IOSession.getFilterChain().addFirst("protocolFilter", new
> ProtocolCodecFilter(codec));
>
>         ...
>     }


Looks very good!

some questions regarding the 2 pools:
>
> 1stpool:
>
> - by default (without a custom pool setup) only this pool would exist?


Yes.

- if only this pool exists it will be used to execute io->filter AND
> filter->handler?


Yes.

- is is guaranteed that filter->handler for a specific connection is called
> SEQUENTIALLY which would in my case guarantee that ONE and ONLY ONE textline
> of a specific connection is forwarded to my handler?


Exactly.  But this is also true however many thread pool you insert because
MINA guarentees the order of events.

2ndpool:
>
> -  if this is available the 1st pool will only exectute io->filter while
> this 2nd pool
> with only execute filter->handler?


True.

- i assume this 2nd pool would be beneficial if business logic (in the
> handlers) may be expensive (jdbc stuff i.e.), because with one pool this
> bl would block the filters? if this is the case, would the io
> (sending/receiving) be blocked, too?


Threr's an internal queue in each thread pool, so I/O doesn't block and data
will be stored in the internal queue.  But if your application is too
overloaded, the size of the queue can be too big and cause
OutOfMemoryError.  This means that we have to control the size of that
internal queue, but we didn't implement this feature yet.  Of course, we
will resolve this issue soon.  But in most cases, server developers should
test the performance of the application very carefully before the production
stage, so it doesn't become a problem as often as we usually think.

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