directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [seda] A preview on redesigned SEDA (or Netty?)
Date Wed, 08 Dec 2004 20:23:58 GMT
Berin Loritsch wrote:

> Trustin Lee wrote:
>> Hi,
>> I implemented protocol layer and here is a new example which uses it:

>> It is a server which reverses all text lines client sends and reply 
>> back.
>> I want to know how you guys feel this API, so please leave some
>> comments here! :)
>> BTW I decided to name this new API as 'MINA'.  MINA means 'A
>> Multipurpose Infrastructure for Network Applications', 'South' in
>> Japanese, or just a girl's name.  HDYT?
> Does it use the ProtocolHandler interface that
> the old SEDA system did?  That is one of the goals I have.
Yep this was a big concern for me that I've reiterated to Trustin.  
However wrappers are not out of the question if I don't have to write 
them ;).

> I'd like to see the difference in how these perform as well as how 
> easy it is to work
> with.  If it looks like mina is easier to work with and seda is more 
> scalable, we might
> look at merging some concepts.
Yep my thoughts exactly.  MINA will respond fast when the number of 
users is small.  SEDA on the other hand will scale better with load.  
MINA reponsiveness will outperform SEDA bellow some threshold.  But SEDA 
will scale better.  In the end servers with long living TCP connections 
may benefit more from SEDA than MINA.

I think the best approach is to play with all of them :).  I'm not 
adverse to having two or more different networking layers to work with.  
Even two layers in the same framework for that matter that compliment 
one another.  

This does however place more importance on the ProtocolProvider 
interfaces.  If there are adapters then this should be managed behind 
the scense by the networking layer.  This way we can snap in the LDAP, 
Kerberos and other protocol providers into the two framework 
implementations without alteration.  This interop should be provided so 
we can really test these frameworks side by side even in the same server 
instance using different ports for the same protocol served by two 
different networking layers.   Sick as it sounds it will help us get 
some statistics.


View raw message