mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: MINA 3.0 status
Date Thu, 30 Jun 2011 16:17:39 GMT

On Jun 30, 2011, at 12:17 AM, Ashish wrote:

> On Thu, Jun 30, 2011 at 12:42 PM, Emmanuel Lecharny <elecharny@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<jvermillard@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


Mime
View raw message