directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Wallace <rwall...@thewallacepack.net>
Subject Re: [seda] A preview on redesigned SEDA (or Netty?)
Date Wed, 08 Dec 2004 17:20:51 GMT
Hey guys,

I'd like to chime in if I might.  A network admin friend and I have 
decided to write a mail server in Java in our spare time, just for the 
fun of it.  I'm eager to play with using SEDA to handle the flow of 
operations, and was hoping I could use the SEDA library in this project 
as the basis for that.

I'm a little confused on what you guys are discussing right now, tho. 
Most of what you seem to be talking about sounds like a pipeline with a 
fixed number of stages in it.  The reason I say this is because of the 
ProtocolHandler class.  It seems to me that you would also want to break 
up the ProtocolHandler into different stages.

For instance, in Matt Welsh's http server, Haboob, he had several stages 
dealing with cache and file IO and dynamic page generation.  I plan on 
looking to do something similar in the mail server my friend and I are 
getting ready to write.

I'm curious how this type of ProtocolHandler would be constructed in 
Mina and Berin's SEDA implementation (I can't wait to see more code 
there).  Would you need to build a sort of sub-pipeline within the 
protocol handler to accomplish this?  I think it is very important that 
it is easy for someone to be able to plug in a new ProtocolHandler and 
be able to take advantage of the concurrency and scalability that the 
non-blocking IO and SEDA provide, but it should also be fairly 
straightforward to build new pipelines.

Everything I've seen so far looks great.  I'm eager to try this stuff 
out in my own project.

Rich

Berin Loritsch wrote:
> 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.
> 

Mime
View raw message