You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Julien Vermillard <jv...@gmail.com> on 2011/06/06 11:46:18 UTC
MINA 3.0 status
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
Re: MINA 3.0 status
Posted by Ashish <pa...@gmail.com>.
On Thu, Jun 30, 2011 at 9:47 PM, Alan D. Cabrera <li...@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<jv...@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
Re: MINA 3.0 status
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jun 30, 2011, at 12:17 AM, Ashish wrote:
> On Thu, Jun 30, 2011 at 12:42 PM, Emmanuel Lecharny <el...@gmail.com>wrote:
>
>> On 6/30/11 8:11 AM, Ashish wrote:
>>
>>> On Mon, Jun 6, 2011 at 3:16 PM, Julien Vermillard<jv...@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
Re: MINA 3.0 status
Posted by Ashish <pa...@gmail.com>.
On Thu, Jun 30, 2011 at 12:42 PM, Emmanuel Lecharny <el...@gmail.com>wrote:
> On 6/30/11 8:11 AM, Ashish wrote:
>
>> On Mon, Jun 6, 2011 at 3:16 PM, Julien Vermillard<jv...@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 ;)
>
> 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
Re: MINA 3.0 status
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 6/30/11 8:11 AM, Ashish wrote:
> On Mon, Jun 6, 2011 at 3:16 PM, Julien Vermillard<jv...@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
(LOGGER.isDebugEnabled()).
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 !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: MINA 3.0 status
Posted by Ashish <pa...@gmail.com>.
On Mon, Jun 6, 2011 at 3:16 PM, Julien Vermillard <jv...@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.
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
}
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?
For benchmarking, can we use EC2?
thanks
ashish
Re: MINA 3.0 status
Posted by Julien Vermillard <jv...@gmail.com>.
On Mon, Jun 6, 2011 at 12:19 PM, Niklas Gustavsson <ni...@protocol7.com> wrote:
> On Mon, Jun 6, 2011 at 11:46 AM, Julien Vermillard
> <jv...@gmail.com> wrote:
>> 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 ?
>
> With "test env" you mean for load/performance testing. Infra doesn't
> have that at the moment, but it's worth asking as to give input into
> what's needed. I know Lucene has requested a load testing environment
> as well, perhaps we could share.
>
Yes I mean perf tests :) Infra asked to workout a request with the
type and number of machines needed.
Julien
Re: MINA 3.0 status
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Mon, Jun 6, 2011 at 11:46 AM, Julien Vermillard
<jv...@gmail.com> wrote:
> 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 ?
With "test env" you mean for load/performance testing. Infra doesn't
have that at the moment, but it's worth asking as to give input into
what's needed. I know Lucene has requested a load testing environment
as well, perhaps we could share.
/niklas
Re: MINA 3.0 status
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jun 16, 2011, at 1:23 PM, Julien Vermillard wrote:
> Hi,
> Answer inline
>
> On Thu, Jun 16, 2011 at 6:34 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>
>> Very cool! I have a few questions.
>>
>> Why have a class for WriteQueue and not simply use Queue<WriteRequest>?
>
> Was my first thought actually WriteQueue is an empty extends of
> Queue<WriteRequest>
> I think we can change it to Queue because I see no needs of custome
> fields/method there.
>
>> Why have an interface WriteRequest and not simply use Object?
>>
> It's for keeping the reference to the future and complete it once the
> message is sent.
Not sure that a WriteRequest is required for that. Couldn't you store the future in a map keyed off the object?
>> Why do we have IoSessionFuture, CloseFuture, ConnectFuture and WriteFuture and not simply use Future<>?
>>
> I didn't took a look at Future for now, but yes I think killing
> IoFuture and trying to stick to java 5.0 Future is the idea.
You should take a look at my IoFuture. I've extended it to allow for clients to register listeners. Quite handy.
>> A long time ago I also took a stab a Mina 3 API. Mine was driven by an async HTTP implementation. It would be neat if we could merge the two sets of ideas; not sure how much time I can devote to this in the short term though. :)
>
> Same here, it's going slow but continuously anyway keep dropping ideas !
Very cool. I'll still keep updating my copy in the sandbox to incorporate your stuff as well. It will serve as a nice comparison between what you have on your branch and mine.
Regards,
Alan
Re: MINA 3.0 status
Posted by Julien Vermillard <jv...@gmail.com>.
Hi,
Answer inline
On Thu, Jun 16, 2011 at 6:34 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> Very cool! I have a few questions.
>
> Why have a class for WriteQueue and not simply use Queue<WriteRequest>?
Was my first thought actually WriteQueue is an empty extends of
Queue<WriteRequest>
I think we can change it to Queue because I see no needs of custome
fields/method there.
> Why have an interface WriteRequest and not simply use Object?
>
It's for keeping the reference to the future and complete it once the
message is sent.
> Why do we have IoSessionFuture, CloseFuture, ConnectFuture and WriteFuture and not simply use Future<>?
>
I didn't took a look at Future for now, but yes I think killing
IoFuture and trying to stick to java 5.0 Future is the idea.
> A long time ago I also took a stab a Mina 3 API. Mine was driven by an async HTTP implementation. It would be neat if we could merge the two sets of ideas; not sure how much time I can devote to this in the short term though. :)
Same here, it's going slow but continuously anyway keep dropping ideas !
Julien
Re: MINA 3.0 status
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 6/16/11 6:34 AM, Alan D. Cabrera wrote:
> On Jun 6, 2011, at 2:46 AM, Julien Vermillard 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
>
> Very cool! I have a few questions.
>
> Why have a class for WriteQueue and not simply use Queue<WriteRequest>?
>
> Why have an interface WriteRequest and not simply use Object?
>
> Why do we have IoSessionFuture, CloseFuture, ConnectFuture and WriteFuture and not simply use Future<>?
Those are all good questions. No time to think about it this morning,
but definitively something I'll give some thought later today.
> A long time ago I also took a stab a Mina 3 API. Mine was driven by an async HTTP implementation. It would be neat if we could merge the two sets of ideas; not sure how much time I can devote to this in the short term though. :)
We are all on the same page ith the same problem : lack of time :) But
we will fix this problem too !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: MINA 3.0 status
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jun 6, 2011, at 2:46 AM, Julien Vermillard 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
Very cool! I have a few questions.
Why have a class for WriteQueue and not simply use Queue<WriteRequest>?
Why have an interface WriteRequest and not simply use Object?
Why do we have IoSessionFuture, CloseFuture, ConnectFuture and WriteFuture and not simply use Future<>?
A long time ago I also took a stab a Mina 3 API. Mine was driven by an async HTTP implementation. It would be neat if we could merge the two sets of ideas; not sure how much time I can devote to this in the short term though. :)
Regards,
Alan