directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject Re: [seda] A preview on redesigned SEDA (or Netty?)
Date Wed, 08 Dec 2004 16:34:56 GMT
Trustin Lee wrote:

>Hi.  I'm glad to see some comments finally. :)
>
>  
>
>>The process of setting up the system is not too different from my
>>thoughts on it.
>>    
>>
>
>Good.
>
>  
>
>>I'm sure the internals are going to be very different from our two
>>thought processes.
>>    
>>
>
>Could you explain your thought process?  I think we need to cooperate.
>  
>
I'm used to the SEDA style event model, and I'm not really straying that 
far from
it.  However, I am optimizing on certain event types in the sense that I 
am not
introducing new events when the events that are generated from NIO will 
work.
I'm also streamlining things a bit in the sense of each stage does one 
thing, and
does it well--which is supposed to be its strength.

>>You had a head start on mina, so you got it done sooner :).  Anyway, I
>>haven't
>>really looked into the internals yet.  Does it use the ProtocolHandler
>>interface that
>>the old SEDA system did?  That is one of the goals I have.
>>    
>>
>
>No, but we can migrate very easily.  I'm not using snickers yet, but
>I'll provide a wrapper for it.
>  
>

As will I.  My approach will be to add stages for each part of the 
ProtocolHandler
object (encoder, decoder, etc.).  Howeer, everything else will be fairly 
familiar and
standard.  I am using a very stable and well tested event routing 
library so as not
to have to reinvent the wheel on that.

>>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.
>>    
>>
>
>I expect MINA to perform better than SEDA for a few reasons:
>
>1. MINA doesn't create events and bytebuffer instances frequently.
>2. MINA has constant route calculation time. (SEDA takes O(n) time)
>
>But MINA can be slow too because she provides more complex event
>hooks, and she has only one I/O thread. (SEDA has one for read and the
>other for write.)
>  
>
My expectation is that we will have the assembly line syndrome.  IOW, 
for small
production runs it doesn't really make sense, but when you really need 
to crank
it does better.

The thread management for the SEDA environment I am creating is 
configurable.
It can be only one thread, or it can be a proportion of threads to the 
number of
processors, or it can be something much more complex (with multiple thread
pools, etc.).  The library I am using already has a ThreadManager and a 
couple
ThreadPolicies written.

>Her strength is in its freedom; you can use only core packages or can
>use higher-level protocol package.  You can run your network
>application in a single thread or in a thread pool.  Basically MINA
>doesn't care if the user logic runs together with internal I/O thread.
> It is absolutely 100% up to the API user.  This flexibility is
>accomplished by decorator pattern.  Currently MINA lacks rich set of
>decorators, but I'll add them sooner or later.  Here is a possible
>example:
>
>Acceptor acceptor = new TcpAcceptor();
>acceptor.bind(new InetSocketAddress(8080),
>ThreadPooledSessionHandler.decorate(CoreAdapter.adapt(new
>MyProtocolProvider()), /* TP size */ 16));
>  
>

I was thinking that the ProtocolHandler wrapper doesn't really care how 
things
are going under the scenes, but if they wanted they could have a simple 
way of
adjusting it.

For example, the SEDAServer is pretty much hard-coded in the sense that
the pipelines are set up.  You can adjust things in this manner:

// Yes its a singleton, but for good reason
SEDAServer server = SEDAServer.getServer();
Firewall firewall = server.getFirewall();
firewall.deny(InetSocketAddress("127.0.0.1", 6666);

server.addProtocol( 8080, new HTTPProtocolHandler() );

// (And things would just work)

server.removeProtocol( 8080 );

// (And it is now uninstalled )

Now, if the user wanted to adjust the threadpolicy, I could
enable something like this:

SEDAServer.getServer().installPolicy(new SingleThreadPolicy());

That would stop the old ThreadManager, and restart everything with
the new thread policy.  Of course I can add some protections around it
as well.

-- 

"Programming today is a race between software engineers striving to build bigger and better
idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far,
the Universe is winning."
                - Rich Cook


Mime
View raw message