On Jun 30, 2011, at 12:17 AM, Ashish wrote: > On Thu, Jun 30, 2011 at 12:42 PM, Emmanuel Lecharny > <elecha...@gmail.com>wrote: > >> On 6/30/11 8:11 AM, Ashish wrote: >> >>> On Mon, Jun 6, 2011 at 3:16 PM, Julien >>> Vermillard<jvermillard@gmail.**com<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/<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 ;)
What objects get created? Just curious. Regards, Alan
