Serge Baranov wrote:
Hello David,
Wednesday, April 22, 2009, 1:00:38 AM, you wrote:
D> No advice? :-(
There is nothing wrong with using a thread pool executor before the
codec in the chain. It would depend on your application. We found that
in our case the performance is much better when executor is first
since all the operations are performed in parallel just after
sessionCreated and are not limited to the IoProcessor threads.
You can see that Apache FtpServer project based on MINA is using this
approach:
http://www.google.com/codesearch/p?hl=en#-Df7BeIx838/trunk/core/src/main/java/org/apache/ftpserver/listener/nio/NioListener.java&l=149
(notice that threadPool is added before codec for the acceptor).
Thanks much for the message, Serge. (And sorry for the late response.)
Interesting to hear your experiences. Makes sense about having the
executor first. (It's also interesting, since it directly contradicts
what the OP originally told me.)
Still, wouldn't it also make sense to have a thread pool on writes as
well? That way once a message has been processed, the reader/processor
thread can just dump the response message into a queue for output,
thereby freeing up the reader thread to process new incoming messages.
Seems like in theory you could handle a lot more message throughput by
decoupling message reading from writing like this.
Am I offbase in my assumptions here?
Thanks,
DR
