Re: FW: Re: [seda] Re: SEDA

Word of warning concerning the 'Avalonized version of Seda':
I looked into it ... 1) it had numerous bugs, like no one
actually used it!; 2) it did polling (IMHO an application that
polls gets a D); and 3) I ended up re-writing all of it.
So, its basically an interesting idea but its only the beginning.

RME


Tim Walker wrote:
> 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
> _______________________________________________
> SEDA-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/seda-users
> 




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