mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: MINA 3.0 status
Date Thu, 30 Jun 2011 07:12:24 GMT
On 6/30/11 8:11 AM, Ashish wrote:
> On Mon, Jun 6, 2011 at 3:16 PM, Julien Vermillard<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/
>> 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.

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 

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 !

Emmanuel L├ęcharny

View raw message