Hi Horace,
On 9/13/06, Horace Pinker <[EMAIL PROTECTED]> 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
