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 00:10:33 GMT
Hello again,

> From:
> Quoting Tim Walker <>:
> > 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.

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

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.

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.

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

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 

Hope that clarifies my approach and whether or not that approach is
worth a simple commons based subproject.  What do you guys think?


View raw message