Leo Sutic wrote:
Berin,
nice work as usual.
However, architecturally I have some random thoughts that I'd like to share.
I have looked into SEDA as part of my Avalon-for-C++ project, and regarding
queues, I can not really say whether the queue should or should not be exposed
to the stages producing events for that stage.
Keep in mind that in the SEDA system, Sandstorm Kernel, stages are decoupled
from each other
by the queues. The Stage is given a set of Sinks from the Manager. The Sinks
are in reality
the beginning of the queue (since in SEDA, the concepts are Stage-centric
rather than Queue-
centric). The Stage has no control over what queue is assigned to it. This is
not really a
problem.
In essence, a system can be completely redesigned at runtime by the manager.
The queues can
be reassigned to connect to other stages, etc.
This is FS (Flexibility Syndrome), but it drives home the point that Stages
need to be
decoupled.
There are a couple of ways of dealing with the system, but while Queues do
introduce a latency,
they do allow the system to scale evenly. It also allows for multiple threads
to adaptively
help queues that reach a certain threshold of backpressure (i.e. the following
stage cannot
keep up processing events).
In the end, you will find that queues are in the end a better solution to
direct coupling.
Axiom: Stage isa Component
Scenario:
class StageBeforeMyStage implements Stage { ... }
class MyStage implements Stage { ... }
class MyStageWorkElement implements QueueElement {
public MyStageWorkElement (String workDescription) { ... }
public String getWorkDescription () { ... }
}
StageBeforeMyStage produces MyStageWorkElements and feeds them to MyStage.
Now, I thought like this: The queue should hold event objects. But C++ templates enables you to design the queues with type safety - that is, you do not need to cast the event object after dequeueing it. This is a major advantage, as you do not need to rely on the previous stage producing the correct work elements.
Hmm. What about Events like QueueClosed, or other control events that go
through the same queue?
Not every queue will be passing references to Sockets or File Handles. They
will be passing control
events as well. I don't think this is one place where templates while a cool
feature won't help
the Queue implementation--esp. with respects to the type of events.
I imagine StageBeforeMyStage will use a ComponentManager to
lookup(MyStage.ROLE). Now, what does StageBeforeMyStage see of MyStage? Does it
see the Sink interface?
I would propose that it did not.
Keep in mind the statements mentioned above regarding scalability. Also, keep
in mind
that I requested the review of the Queue interfaces--I haven't even begun to do
the
Stage implementation.
We can attempt different approaches at that time, however, I have other uses
for the
queue than for just the stages.
I would like to show this interface:
interface TransactionalSink {
public void beginTransaction ();
public void commitTransaction ();
public void abortTransaction ();
}
See my replacement for this. It is soo much better.
interface MyStageSink extends TransactionalSink {
public void addWorkDescription (String workDescription);
}
The usage would then be like this:
MyStageSink sink = (MyStageSink) manager.lookup (MyStageSink.ROLE);
.
.
.
try {
sink.beginTransaction ();
sink.addWorkDescription ("Do this.");
sink.addWorkDescription ("Do that.");
sink.commitTransaction ();
} catch (Exception e) {
sink.abortTransaction ();
}
A stage would then be just like a component with asynchronous methods. The thread pool for each stage would be managed by the component manager the stage belongs to.
-1
You are mixing some key concerns. A ComponentManager != SystemManager. It is
not the ComponentManager's role to maintain thread pools for the system. Also,
you are limiting the Queue to using strings--which is too limiting. There are
a number of different types of events from opening a file, to actually reading
information from it. All of these can come from a pipeline--if the stage doen't
handle it, than just like the nice Swing counterpart, it should pass the event
on....
We have QueueElements to mark the types of objects that can go in the queue,
and that should be enough. If we need to open it some more, we can make them
simple objects. But I don't think that the direct coupling of stages would be
a good pattern.
Stages != Components either. Stages ~ Filters. I think we should strive for
conceptual simplicity while we are implementing this. I mean the guy that wrote
SEDA not only has a Ph.D., but it doesn't seem to be of the variety where it is
Piled Higher and Deeper (assuming you start with B.S.).
I think we should learn from the lessons that Matt Welsh put forth, as they are
tested and not purely theorhetical.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
