directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Re: [seda] Re: SEDA
Date Wed, 14 Jan 2004 17:43:17 GMT
Thanks again for all your input.  I need to do some research on the event 
package again.


> From: Berin Loritsch <>
> Date: 2004/01/14 Wed AM 11:02:44 EST
> To: Alex Karasulu <>
> CC: Apache Directory Developers List <>
> Subject: Re: [seda] Re: SEDA
> Alex Karasulu wrote:
> > Hello again,
> > 
> > 
> >>From:
> >>Quoting Tim Walker <>:
> >>
> >>
> >>>This is very interesting. Is the 'Avalonized version of Seda' a rewrite?
> >>>thoughts on the motivation for
> >>>the rewrite in Eve?
> > 
> > 
> > Tim I have looked at the event stuff in Excalibur in the past and 
> > should probably revisit it before responding but well I'm runing on
> > low fuel now adays so I'll just state that it was more complex for
> > my needs.  Also I think it was geared to use sandstorm I think.
> > 
> > My view of SEDA may be a bit oversimplified.  I view a stage as 
> > a event source or sink.  Events are enqueued onto the event queues
> > of stages.  Enqueue predicates associated with the stage are used
> > to determine if the enqueue operation should occur or not.  Stages
> > have a thread pool.  A stage handler dequeues events delegating 
> > processing to a worker thread.  The worker thread processes the 
> > event possibly generating other events which are handled by other
> > stages.
> A stage is a specified location where events are processed and generated.
> The event queues are used to connect these stages together.  This is the
> core principle of SEDA style implementation.  Each stage is essentially
> a component, and they are wired together via a common interface.
> > Now these APIs I looked at had all the fancy stuff like setting
> > up the source to sink mapping and some other features of a SEDA.
> > I did not want to get carried away with this in Eve and just
> > implemented simple stages without the bells and whistles.  The
> > goal was to simply have staged processing.  The SEDA stuff I have
> > encountered in the past left me with the feeling that connection 
> > handling with non-blocking IO was too integrated with the simple 
> > structures needed to implement SEDA.  I wanted to decouple the
> > connection handling from the fact that the architecture is based
> > on staged processing of requests.  Really the way you handle 
> > connection establishment, reads, writes and droping connections
> > will be application and implementation specific so why mix the
> > two together.  Also don't presume you have to be non-blocking 
> > to implement SEDA.  With continuations you can use blocking sockets
> > to multiplex IO handling.  So the less presumptions we make the
> > more useful the API.  Also Eve is complex enough so what
> > ever simplifications I can make wrt the implementation without
> > loosing the benefits the more maintainable the code will be.
> The stuff over at Excalibur is actually three distinct sections:
> 1) The core event API which includes the queues, listeners, and
>     predicates/interceptors.
> 2) The commmand architecture which is a specialized Stage that is
>     designed to run arbitrary commands in a set number of threads.
> 3) Managed pool implementation which uses the command architecture
>     to schedule the pool maintenance tasks.
> The whole system uses Doug Lea's excellent concurrency tools which
> will be made part of JDK 1.5 in some form.  This is great news,
> but it also lets you know that the thread pool implementation is
> done by someone who knows what they are doing.
> What is there will allow you to build a SEDA container on top of
> it, but it is only partially there.
> > Take for example the code associated with dynamic source->sink
> > mappings.  These are all nice features to have when you want to
> > dynamically inject a new instrumentation stage between two stages
> > to measure the throughput or whatever.  Why bother with it if the
> > relationships between your stages are to be static.  Also if 
> > one wanted to add an extra stage simply changing your container 
> > configuration would allow you to do so with relative ease and
> > if designed properly it may be a configuration change not a code
> > change.  Lot's of IoC containers like Merlin will allow you to 
> > do this with a restart.  Merlin may even get to the point soon
> > where it can do it dynamically further lessening the need to have
> > source->sink dynamic mappings.
> The purpose of the event queues has little to do with dynamic architecture--
> although that is an additional benefit of this approach.  The purpose
> of the event queues is to manage load.  The best way to look at it is
> mass production.  The queues are like the conveyor belts that move the
> work from machine to machine (stage to stage).  More work gets done
> overall because more things are being processed at the same time.
> How many factories reroute the conveyor belts dynamically?  If there
> are multiple routes, the machines will make a decision in real time
> as to which route the piece of work should go.
> > BTW Berin Loritsch from Avalon probably can explain the Excalibur 
> > stuff better so I have CC'd him in case he wants to plug in.  Note 
> > also that Excalibur may serve your needs - it's good stuff but I
> > was looking for only half of it.
> I'll do my best.
> >>The events package isn't so much a rewrite as it is a different approach using
> >>the same ideas.  I'm no expert on the events package in excalibur but from what
> >>I understand it is meant as a more general solution following the Avalon design
> >>philosophy (i.e. IoC, etc.).
> The event package allowed better IoC, and much less class entanglement than the
> student project that Matt Welsh put together.  He is an incredibly smart person,
> but typically student projects don't reflect lessons learned in the real world
> very well.
> > Mr. Wallace (Don't have your first name),
> > 
> > Absolutely I agree, you're dead on target.  I think the Avalon stuff
> > started off as Silk if I remember correctly.  But it moved into Excalibur
> > and became the event project under the Excalibur umbrella.
> Something along those lines.
> > If I had my way I would implement SEDA classes as POJOs within an
> > API and borrow from whatever I can in commons.  James Strachan has
> > a nice little thread pool so I'd use that.  There are queues in the
> > collections packages and you can decorate them with the ability to
> > consult enqueue predicates but I think someone must have already beat
> > us to it.  I would then use these vanilla classes with the various 
> > IoC containers frameworks to create container specific wrappers 
> > around the Stage POJO implementation.  This way you can remain container
> > independent and reuse as much tested tried and true commons code as 
> > possible.  
> Feel free to try.  The Event package was created because the original
> offering was too convoluted to really incorporate into your own work.
> -- 
> "They that give up essential liberty to obtain a little temporary safety
>   deserve neither liberty nor safety."
>                  - Benjamin Franklin

View raw message