On Thu, Jun 30, 2011 at 12:42 PM, Emmanuel Lecharny <[email protected]>wrote:
> On 6/30/11 8:11 AM, Ashish wrote: > >> On Mon, Jun 6, 2011 at 3:16 PM, Julien >> Vermillard<jvermillard@gmail.**com<[email protected]> >> >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/<http://svn.apache.org/repos/asf/mina/branches/3.0/> >>> >>> Here the current Javadoc : >>> http://people.apache.org/~**jvermillard/mina-3.0/apidocs/<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. >> > > LOG/LOGGER, not really a big deal. :) > > 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 >> } >> > > It's not necessary. Doing a LOGGER.debug( "xxx{}", blah ); does the same > thing (ie check if the logger is in debug mode, and if so, returns > immediately). It's only if you have a complexe formating (ie with more than > 2 parameters) that it could be usefull to use a if > (LOGGER.isDebugEnabled()). > just to avoid those objects to be created :) not very touchy about this, as readability is equally important. It was just a crazy thought ;) > > Another possibility would be to define LOGGER as static, the the if (...) > can be removed at compile time. > > 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? >> > Sure ! > > > For benchmarking, can we use EC2? >> > Yes, we can ! > > Lets work out some specs of what we want test and I can take it up :) thanks ashish
