mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ashish <paliwalash...@gmail.com>
Subject Re: MINA 3.0 status
Date Mon, 04 Jul 2011 05:09:07 GMT
On Thu, Jun 30, 2011 at 9:47 PM, Alan D. Cabrera <list@toolazydogs.com>wrote:

>
> 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.
>
>
All the logs statements if executed shall have objects instances, now if we
skip the execution those objects shall be skipped.
More troublesome are the toStrings() where object states are dumped.

That said, we are relatively safer with slf4j, as toString() is not called
till its being written to a stream, and it internally has the check that I
was pointing to :)

thanks
ashish

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message