FW: Re: [seda] Re: SEDA

Hi, 

Just wanted to pass along a thread involving the use of SEDA in the Apache Directory project. 

Hope this finds you all well. 

Best regards, 

--
Tim 


-----Original Message-----
From: Richard Wallace [mailto:[email protected]] 
Sent: Tuesday, January 13, 2004 5:36 PM
To: [email protected]
Subject: RE: Re: [seda] Re: SEDA

Quoting Alex Karasulu <[email protected]>:

> Hello again,
>
> > From: [email protected]
> > Quoting Tim Walker <[email protected]>:
> >
> > > This is very interesting. Is the 'Avalonized version of Seda' a rewrite?
> Any
> > > 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.
>

I doesn't use anything from sandstorm.  It just takes inspiration from it.  I
looked at it a while ago too and just revisited it today.  Before it didn't
really seem complete, but it does now.  And it seems simpler to me than the
Sandstorm implementation (though I don't think my understanding is complete
yet).

> 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.
>

That's is my understanding.

> 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.
>

In the Excalibur event package there is no use of NIO or anyother kind of IO. 
It has ThreadManager's which handle processing of events.  It has the
CommandManager which, in my understanding, represents a stage.  Then there are
a couple of queues (DefaultQueue grows, FixedSizeQueue doesn't).  There are a
couple kinds of Sinks (which is where my understanding is a bit short).  And
there are some EnqueuePredicates.  My biggest question in the existing event
package is how an event (called a Command in Excalibur events) moves from one
stage to the next.  I don't see any mappings between source and sink, though I
may be missing something.  From my understanding right now it seems the
EventHandler would decide what the next CommandManager (Stage) to which the
command (event) should be sent.

> 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.
>
> 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 would love to get Berin's input on this since this was his baby.

> >
> > 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.).
> >
>
> 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.
>

Yup, that sounds right to me.

> 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.
>
> Hope that clarifies my approach and whether or not that approach is
> worth a simple commons based subproject.  What do you guys think?
>

I have mixed feelings about commons.  Most of them have already been mentioned
before and I don't want to start a war here over it so I'll just say that I
think the stuff in Excalibur events is, at the very least, a good starting
point for any type of SEDA development.  If you find it's not adequate maybe
changes should be made within the event package.  This is especially true if
you are already planning on using the Avalon framework and the Merlin
container.

Rich

> Alex
>
>
>


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html