On Mon, Jun 6, 2011 at 3:16 PM, Julien Vermillard <jvermill...@gmail.com>wrote:
> Hi ! > Just a few heads up on current work on MINA 3. > > As stated before, we are re-writing from scratch (but using MINA well > know interface/concepts) a simple NIO TCP server for experimenting > different strategy around NIO selector. > > The work is done on this branch : > http://svn.apache.org/repos/asf/mina/branches/3.0/ > > Here the current Javadoc : > http://people.apache.org/~jvermillard/mina-3.0/apidocs/ > > Actually the NioTcpServer accept connections, write some basic bytes > and read incoming data in a SelectorProcessor. A SelectorProcessor is > a thread selecting/polling a bunch of sockets. > > The main design change is the SelectorStrategy idea : > When you create a Service (server or client) you provide a > SelectorStrategy which will be in charge of providing the > SelectorProcessor for the different operations (accept, read, write). > So we can implements (and seriously benchmark) different SelectorStrategy > like : > - OneThreadSelectorStrategy (currently implemented) which will spawn > only one SelectorProcessor for handling all the operations > (accept/read/write) > - a processor thread for read, another for write, another for accept > - a processor thread for each CPU > - ... > > The idea is to stress test few ideas and find the winning scenario > for common use cases (connection less like HTTP, long living sessions, > write intensive protocols, latency, etc..) > > I now need to plug a serious API for writing real tests : IoHandler > and perhaps a filter chain and a test environment. > > For the IoHandler/ chain I'll dig in the ML archive, a lot of idea was > proposed, but for the test env, I'm a bit puzzled, does I'm supposed > to ask resources to infra ? > > Any help/patch/review comment on the code is welcomed even if I > haven't much hope :) > Julien > Finally had a chance to look into the work :) First glimpse, like the simplicity. Classes are more intuitive to use. Just few thoughts 1. Would like to have the logger usage as we have it in existing version. Just the naming, instead of LOG, would propose to use LOGGER :) minor one. 2. Do we want to wrap the log statements inside the condition that it should be executed only if the particular log level is enabled like if(LOGGER.isDebugEnabled()) { LOGGER.debug();// blah blah } just a thought, it adds clutter to code, but helps at runtime 3. Can we plan to use java.util.concurrent.locks.Lock class instead of synchronizing on objects instances or this? For benchmarking, can we use EC2? thanks ashish
