Further Examination of SandStorm Code

[Berin Loritsch <bl...@apache.org>]

After re-examining Matt Welsh's SandStorm server kernel, I have come to
the conclusion that Stages conceptually are the EventHandlers.  The
confusion came from studying the interfaces and reading his thesis.
While the concepts relate, the names are somewhat different.  In
SandStorm (his SEDA kernel), the Stage is merely an object to manage
stage/queue relationships.  The EventHandler is where the real work is
done.  In fact, after examining the Haboob HTTP server code, there is
no class that extends Stage or directly implements Stage.  There is
only the classes the implement EventHandler.

Because of this conclusion, I will make the Stage interface in
Cornerstone extend EventHandler.  It is in fact the correct thing
to do.  Once I have the interfaces defined, I will put together a
re-implementation of the nonblocking connection management code, and
asynchronous file IO code.  I will make these specific stages, but
I am unsure of how to expose it via the normal Block Interface.

I am open to suggestions of how to reconcile the Stage and Block
pieces.  I see how some of it will work together quite nicely,
but I also see how some of it will overlap.

Here are places of overlap:

ConnectionManager, SocketManager, ObjectStore

Here are places that compliment:

DataSourceSelector, TimeScheduler


The big thing is that driving the architecture with events is a very
different model.  I personally would prefer to have portions of files
read and the information passed as QueueElements.  Bringing this into
the world of JDK 1.4 with the new Buffer classes, we could have a
Cache stage that had a pool of MappedByteBuffers that had direct to
memory mapping for a group of files.  This implementation allows us
to read in a chunk of the file automatically, pass it in a BufferMessage
that eventually gets serialized via nonblocking IO to the client.
In fact, with such a scheme, we can have a portion of several files
open, reading enough in for the next message, and as messages are
consumed, we reuse them for the next section of the file.

It provides alot of functionality, but I wonder if providing the ability
to separate portions of the event driven architecture accross block
boundaries is a flawed concept.  My original thinking in this line was
to keep the ability to separate a server into ProtocolHandling sections
and Store management sections (i.e. SMTP, POP3, IMAP, mail queue, etc.).
However, that could also be happening at the Stage level.

Any input would be helpful.

----------------------------------------------------
Sign Up for NetZero Platinum Today
Only $9.95 per month!
http://my.netzero.net/s/signup?r=platinum&refcd=PT97

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Further Examination of SandStorm Code

[Peter Donald <pe...@apache.org>]

On Sat, 2 Feb 2002 15:49, Berin Loritsch wrote:
> After re-examining Matt Welsh's SandStorm server kernel, I have come to
> the conclusion that Stages conceptually are the EventHandlers.  The
> confusion came from studying the interfaces and reading his thesis.
> While the concepts relate, the names are somewhat different.  In
> SandStorm (his SEDA kernel), the Stage is merely an object to manage
> stage/queue relationships.  The EventHandler is where the real work is
> done.  In fact, after examining the Haboob HTTP server code, there is
> no class that extends Stage or directly implements Stage.  There is
> only the classes the implement EventHandler.

yep ;)

> I am open to suggestions of how to reconcile the Stage and Block
> pieces.  I see how some of it will work together quite nicely,
> but I also see how some of it will overlap.

Heres how I would do it and how I have done similar things in the past.

* EventRouter: Create a block that allows you to set up the route through 
SILK stages programatically (like attached interface).

* EventHandlerRegistry: create a block that acts as a registry for factories 
of different eventHandlers. (used by RouteConfigurator)

* RouteConfigurator: Create a block that reads in a user specified config 
file and uses that to set up EventRouter block.

Create blocks or vanilla classes that implement the eventhandler factories 
and somehow have these placed in registry.

Then implement the application specific glue code and event handlers. It may 
look like a lot of uneeded abstraction but it has served me relatively well 
so far. Especially the abstraction between EventRouter and EventConfigurator.

> It provides alot of functionality, but I wonder if providing the ability
> to separate portions of the event driven architecture accross block
> boundaries is a flawed concept.  My original thinking in this line was
> to keep the ability to separate a server into ProtocolHandling sections
> and Store management sections (i.e. SMTP, POP3, IMAP, mail queue, etc.).
> However, that could also be happening at the Stage level.

Applicaiton specific call. The SMTP/POP3 protocols (and all other lock-step 
or request-response protocols) generally have a lot of idle time interspiced 
with fixed commands. In these architectures the events would roughly 
corespond to the appearance of a command. Other things like HTTP have 
different layers (ie decode headers, accumulate content, send to logic, 
generate response headers, generate response content).

So in some cases it could be useful to expose EventHandlers as blocks while 
at other times it may be best if EventHandlers were just normal components 
that were created by a "manager" Block.  Im not sure if that helps ;)

-- 
Cheers,

Pete

"You know what a dumbshit the 'average man' on the street is? Well, by
definition, half of them are even dumber than that!"
					J.R. "Bob" Dobbs