You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/01/31 22:24:55 UTC
Silk == More Seda Extractions
Generally impressed with Matt Welsh's work, I began extracting the concepts
for Cornerstone. The issue is that the Stage is a specialized Component
in the system, and we need a clean mechanism to manage inter-block stage
architectures. Enter SILK. SILK is my acronym for Staged Interblock
Linking Kernel. (Hense the continued play on SEDA being the spanish word
for SILK).
The general concept is that a Stage consists of the Component itself (handles
the logic of the stage), a group of input Sinks and one or more output Sinks.
The SilkServer allows a Container to get a SourceMap for any stage that needs
to be connected outside the system.
My connundrum is trying to come up with a way to cleanly tie an EventHandler
to a Stage. Should the stage implement EventHandler, should the configuration
file manage the class to be invoked, or should there be a getHandler() method?
There are pros and cons to each method:
* Stage extends EventHandler
- Really simple design.
- Automatically assures EventHandlers tied to a Stage are always associated
- Limits reuse (i.e. introspective event handlers)
- Maintains IOC
* Config file managed connection
- Carry-over direct from SEDA design.
- Administrator should not have to worry about what handlers get tied to a stage
- Encourages reuse
- Maintains IOC
- Can assure EventHandlers tied to a Stage are associated--but subject to typing errors
- Easy to try new arrangements of EventHandlers and Stage implementations.
* getHandler() method
- Really simple design
- Automatically assures EventHandlers tied to a Stage are always associated
- Encourages reuse
- Not exactly IOC (information and associations passed UP to the container)
Here is the list of intefaces I have already defined:
public interface Stage extends Component {
/**
* Sets the SourceMap for the Stage. This allows the stage to specify
* exactly what Source we are feeding with events. The SourceMap is set
* once, and only once during the life of the stage. Stages are meant to
* be simple components, and the SourceMap is the last method to be called
* during initialization.
*/
void setSourceMap( SourceMap map );
}
public interface SourceMap {
/**
* This gets the main Source for the SourceMap. A SourceMap must have at
* least one Source.
*
* @return the main <code>Source</code> for the SourceMap.
*/
Source getMainSource();
/**
* Get the named Source. If the SourceMap does not contain a match for the
* name, the method throws an exception.
*
* @param name The name of the desired source
*
* @return Source the source associated with the name
* @throws NoSuchSourceException if no source is associated with the name
*/
Source getSource( String name )
throws NoSuchSourceException;
/**
* The SourceArray allows the Stage to get an array of all Sources attached
* to the stage.
*
* @return an array of <code>Source</code> objects. There is at least one
* Source in the array.
*/
Source[] getSourceArray();
}
public interface SilkServer {
/**
* Gets the source for a specified stage name.
*/
SourceMap getSourceMap( String stageName );
}
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Silk == More Seda Extractions
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Mon, 4 Feb 2002 06:12, Berin Loritsch wrote:
>
>>>>The general concept is that a Stage consists of the Component itself
>>>>(handles the logic of the stage),
>>>>
>>>runaway! runaway! runaway!
>>>
>>>Can't we use delegation instead ? ;)
>>>
>>What are you talking about? A Stage is a Component in the SEDA
>>architecture.
>>
>
> You suggested that the Stage ISA EventHandler. Haven't looked at the code
> but thats not how I would design it. I would have the Stage contain a
> reference to the EventHandler. I tend to prefer BlackBox frameworks over
> whitebox ones and thus try to avoid extension via subclassing.
It is not so much subclassing, but a bunch of implemenations of the Stage interface.
Just like there are more than one instance of ConnectionManager, there is more than
one instance of Stage. A stage is black box in the fact that the particular
Stage (EventHandler) manages what it will do with the events given to it. The Stage
is a black box in that its processing is done in one stage, and it forwards events to
the next stage. It is not in control of what Stage feeds it, or what stage it feeds.
That is the responsibility of the application assembler. It also does provide for
a cleaner method of reorganizing the processing of a system that are very similar
to UNIX pipes.
>>>>My connundrum is trying to come up with a way to cleanly tie an
>>>>EventHandler to a Stage. Should the stage implement EventHandler, should
>>>>the configuration file manage the class to be invoked, or should there be
>>>>a getHandler() method?
>>>>
>>>How about another interface "EventHandlerFactory" that is responsible for
>>>creating event handlers or something ? That way any strategy could easily
>>>be implemented by implementing a different EventHandlerFactory object.
>>>
>>No. That is not it. A Stage in essence *is* an EventHandler. I would
>>prefer for stages to remain ThreadSafe, the current design allows for
>>this, and the "EventHandlerFactory" is too much overhead for not enough
>>problem. My issue is reconciling the Block Concept to the Stage
>>concept. All Stages have the same interface, which allows the
>>processing to be done incrementally. Blocks have discrete interfaces,
>>which represent specific units of work.
>>
>
> I understood what you were saying and still think what I was saying holds
> ;)
After reaxamining the code, the EventHandler is not reused, it is the implementation
of the Stage. The StageWrapper and Stage classes that sandStorm has are merely
management classes, and have little to do with the actual processing. I believe that
if we have a Staged architecture, we should have clean units of reuse named Stage.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Silk == More Seda Extractions
Posted by Peter Donald <pe...@apache.org>.
On Mon, 4 Feb 2002 06:12, Berin Loritsch wrote:
> >>The general concept is that a Stage consists of the Component itself
> >>(handles the logic of the stage),
> >
> > runaway! runaway! runaway!
> >
> > Can't we use delegation instead ? ;)
>
> What are you talking about? A Stage is a Component in the SEDA
> architecture.
You suggested that the Stage ISA EventHandler. Haven't looked at the code
but thats not how I would design it. I would have the Stage contain a
reference to the EventHandler. I tend to prefer BlackBox frameworks over
whitebox ones and thus try to avoid extension via subclassing.
> >>My connundrum is trying to come up with a way to cleanly tie an
> >>EventHandler to a Stage. Should the stage implement EventHandler, should
> >>the configuration file manage the class to be invoked, or should there be
> >> a getHandler() method?
> >
> > How about another interface "EventHandlerFactory" that is responsible for
> > creating event handlers or something ? That way any strategy could easily
> > be implemented by implementing a different EventHandlerFactory object.
>
> No. That is not it. A Stage in essence *is* an EventHandler. I would
> prefer for stages to remain ThreadSafe, the current design allows for
> this, and the "EventHandlerFactory" is too much overhead for not enough
> problem. My issue is reconciling the Block Concept to the Stage
> concept. All Stages have the same interface, which allows the
> processing to be done incrementally. Blocks have discrete interfaces,
> which represent specific units of work.
I understood what you were saying and still think what I was saying holds
;)
--
Cheers,
Pete
-------------------------------------------------------
To fight and conquer in all your battles is not supreme
excellence; supreme excellence consists in breaking the
enemy's resistance without fighting. - Sun Tzu, 300 B.C.
-------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Silk == More Seda Extractions
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Fri, 1 Feb 2002 08:24, Berin Loritsch wrote:
>
>>Generally impressed with Matt Welsh's work, I began extracting the concepts
>>for Cornerstone. The issue is that the Stage is a specialized Component
>>in the system, and we need a clean mechanism to manage inter-block stage
>>architectures. Enter SILK. SILK is my acronym for Staged Interblock
>>Linking Kernel. (Hense the continued play on SEDA being the spanish word
>>for SILK).
>>
>
> Kool sounding name ;)
>
>
>>The general concept is that a Stage consists of the Component itself
>>(handles the logic of the stage),
>>
>
> runaway! runaway! runaway!
>
> Can't we use delegation instead ? ;)
What are you talking about? A Stage is a Component in the SEDA
architecture.
>
>
>>a group of input Sinks and one or more
>>output Sinks. The SilkServer allows a Container to get a SourceMap for any
>>stage that needs to be connected outside the system.
>>
>
> So sourcemap is the way that you set up routing between elements? So
> basically sourcemap == routing map ?
No. The SourceMap is to provide the Source/Sources that connect to this
*particular* stage. 9 times out of 10, a Stage will have one Queue
Source to send events to, however there are cases where you have a
multiplexing stage that sends events to two or more pipelines. Case and
point: Cache Stage that will create events to the main pipeline for the
information that it has, but will create events to the cache subpipeline
for information it does not have, so it can resolve the resources.
> The stage itself implements the routing table and also allocates resources to
> each route according to some schedule/load balancing factors?
No, The manager implements the routing table and manages the resources
to each route according to..... You get the picture. The SourceMap is
strictly to get a handle to the queue that forwards events to the next
stage. It does not provide any *global* information. The named queue
concept is so that the Stage can get the particular queue it needs. In
essence the concept is similar to Block resolution.
> If so I don't think exposing sourcemap directly is a good thing. I have
> attached the interface I use for my log server that shows how I set up
> routing tables for it. Maybe that will explain it clearer than my words ;)
It's not what you think. The event routing can be reconnected at any time.
>
>
>>My connundrum is trying to come up with a way to cleanly tie an
>>EventHandler to a Stage. Should the stage implement EventHandler, should
>>the configuration file manage the class to be invoked, or should there be a
>>getHandler() method?
>>
>
> How about another interface "EventHandlerFactory" that is responsible for
> creating event handlers or something ? That way any strategy could easily be
> implemented by implementing a different EventHandlerFactory object.
No. That is not it. A Stage in essence *is* an EventHandler. I would
prefer for stages to remain ThreadSafe, the current design allows for
this, and the "EventHandlerFactory" is too much overhead for not enough
problem. My issue is reconciling the Block Concept to the Stage
concept. All Stages have the same interface, which allows the
processing to be done incrementally. Blocks have discrete interfaces,
which represent specific units of work.
----------------------------------------------------
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: Silk == More Seda Extractions
Posted by Peter Donald <pe...@apache.org>.
On Fri, 1 Feb 2002 08:24, Berin Loritsch wrote:
> Generally impressed with Matt Welsh's work, I began extracting the concepts
> for Cornerstone. The issue is that the Stage is a specialized Component
> in the system, and we need a clean mechanism to manage inter-block stage
> architectures. Enter SILK. SILK is my acronym for Staged Interblock
> Linking Kernel. (Hense the continued play on SEDA being the spanish word
> for SILK).
Kool sounding name ;)
> The general concept is that a Stage consists of the Component itself
> (handles the logic of the stage),
runaway! runaway! runaway!
Can't we use delegation instead ? ;)
> a group of input Sinks and one or more
> output Sinks. The SilkServer allows a Container to get a SourceMap for any
> stage that needs to be connected outside the system.
So sourcemap is the way that you set up routing between elements? So
basically sourcemap == routing map ?
The stage itself implements the routing table and also allocates resources to
each route according to some schedule/load balancing factors?
If so I don't think exposing sourcemap directly is a good thing. I have
attached the interface I use for my log server that shows how I set up
routing tables for it. Maybe that will explain it clearer than my words ;)
> My connundrum is trying to come up with a way to cleanly tie an
> EventHandler to a Stage. Should the stage implement EventHandler, should
> the configuration file manage the class to be invoked, or should there be a
> getHandler() method?
How about another interface "EventHandlerFactory" that is responsible for
creating event handlers or something ? That way any strategy could easily be
implemented by implementing a different EventHandlerFactory object.
--
Cheers,
Pete
---------------------------------------------------
"If you don't know where you want to go, we'll make
sure you get taken."
Microsoft ad slogan, translated into Japanese.
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Silk == More Seda Extractions
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> > If this is the difference between having a single handleEvent() method
> > and having a more do-this-stuff method name such as fetchMailForUser()
> > I see three cases:
> >
> > 1) Synchronous calls through discrete interface. The method
> creates an event
> > and enqueues it, then blocks until completion event is recieved
> or timeout.
>
>
> That is the part that I don't like. Synchronous calls that take
> a long time
> are bad for scalability. However, most of our blocks are fairly quick to
> process events.
True, and this will be a major problem if a stage requires a block. That is,
if MyStage calls MyBlock and the call is synchronous. But I would claim
that that is bad architecture and that if such a bottleneck appears,
the block should be rewritten as a SilkServer with stages.
> > 3) Async call through Stage interface. The event is taken straight into
> > the Silk server.
> >
> > Case 3 is for when you connect a Silk HTTP block with a Silk FileCache
> > block.
>
>
> That would be a common use.
>
>
>
> > So, if we just see the block as a Stage (which it is), there shouldn't
> > be any problems.
> >
> > /LS
>
>
> Cool, but what about case #2, how would you approach that?
Berin,
as I see it, the problem is really in the return value. Suppose
a block exposes this interface:
public interface MyBlock {
public void doStuff () throws SinkFullException;
}
Given that this is the interface for a set of stages served by a
SilkServer, the doStuff method would look like this:
public void doStuff () throws SinkFullException {
SilkServer server = <obtain SILK server>;
Stage stage = server.lookup ("Name of the initial stage - this is where
processing starts.");
stage.enqueue (new DoStuffRequest ());
}
The DoStuffRequest goes through the appropriate stages and eventually
completes. Since the method doesn't return anything, we're done.
It gets trickier if the method must return the result of the processing,
perhaps a success/failure code. Since we must not block, the return value
must be signalled back via an event handler. I would go for this approach:
public interface MyBlockResultHandler {
public void handleResult (String result);
}
public interface MyBlock {
public void doStuff (MyBlockResultHandler handler) throws
SinkFullException;
}
public void doStuff (MyBlockResultHandler handler) throws SinkFullException
{
SilkServer server = <obtain SILK server>;
Stage stage = server.lookup ("Name of the initial stage - this is where
processing starts.");
stage.enqueue (new DoStuffRequest (handler));
}
Once the DoStuffRequest has been processed through all stages, the final
stage calls
the handler.handleResult method to notify the original caller of the result
of the processing.
For example, the ResultHandler could be used in a print spooler system
to continuously provide updates of the progress the document is making.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Silk == More Seda Extractions
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>Keep in mind that the terms of Source and Sink are Queue-centric,
>>not Stage centric. Therefore we are choosing which Queue Source
>>we are pushing events onto. The ThreadManager manages what Queue
>>Sinks to pull information from.
>>
>
> I still do not understand the "queue-centric" view you
> are talking about. A Queue has an end where events go in,
> and an end where events go out. A Queue isa Source and a Queue
> isa Sink.
Correct. The place where events go in is the Queue's Source (i.e.
the source to the queue). The place where the events come out is
the Queues Sink (i.e. the sink to the queue).
> Now, if a source is something where stuff comes out, then
> the Source end of a queue is the end from which you pull
> events. It doesn't matter whether we are viewing this
> from the perspective of the Queue (which recieves items
> by having them stuffed into the Source and delivers them
> to the Sink), as the Source and Sink interfaces are exposed
> to the outside and should be named according to what they expose
> to users. Think about a door: If I put up a sign saying
> "In" on the outside of the door (the outside of the house),
> you'd reasonably well expect that this is the door you go in
> through. But in my "house-centric" view, I mean that this is
> the door where people go in (that is, a person in the house will
> go into/through that door) and you should enter the house
> through the "out" door, since from the inside, you will
> appear to come "out" of that door.
>
> In addition, you get niceties like this (Source.java is full of them):
>
> SourceFullException Indicates that the sink is temporarily full.
> ^^^^
> Which is guaranteed to confuse people.
I see your point. (the JavaDocs were largely copied from sandstorm.
I can change the interface names back to the way that Matt had them.
>>>Would prefer StageManager. SilkServer is too much like "SilkServer(tm)"
>>>and does not immediately associate with what it does.
>>>
>>Names can be changed.
>>
>
> Then please change Source <-> Sink.
Will do. Your explanation above helped me to see why.
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>Blocks have discrete interfaces, which represent specific units of work.
>>
>
> If this is the difference between having a single handleEvent() method
> and having a more do-this-stuff method name such as fetchMailForUser()
> I see three cases:
>
> 1) Synchronous calls through discrete interface. The method creates an event
> and enqueues it, then blocks until completion event is recieved or timeout.
That is the part that I don't like. Synchronous calls that take a long time
are bad for scalability. However, most of our blocks are fairly quick to
process events.
> 2) Async call through discrete interface. As above, but without blocking.
This would be really cool if we can define how to do it.
> 3) Async call through Stage interface. The event is taken straight into
> the Silk server.
>
> Case 3 is for when you connect a Silk HTTP block with a Silk FileCache
> block.
That would be a common use.
> So, if we just see the block as a Stage (which it is), there shouldn't
> be any problems.
>
> /LS
Cool, but what about case #2, how would you approach that?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Silk == More Seda Extractions
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Keep in mind that the terms of Source and Sink are Queue-centric,
> not Stage centric. Therefore we are choosing which Queue Source
> we are pushing events onto. The ThreadManager manages what Queue
> Sinks to pull information from.
I still do not understand the "queue-centric" view you
are talking about. A Queue has an end where events go in,
and an end where events go out. A Queue isa Source and a Queue
isa Sink.
Now, if a source is something where stuff comes out, then
the Source end of a queue is the end from which you pull
events. It doesn't matter whether we are viewing this
from the perspective of the Queue (which recieves items
by having them stuffed into the Source and delivers them
to the Sink), as the Source and Sink interfaces are exposed
to the outside and should be named according to what they expose
to users. Think about a door: If I put up a sign saying
"In" on the outside of the door (the outside of the house),
you'd reasonably well expect that this is the door you go in
through. But in my "house-centric" view, I mean that this is
the door where people go in (that is, a person in the house will
go into/through that door) and you should enter the house
through the "out" door, since from the inside, you will
appear to come "out" of that door.
In addition, you get niceties like this (Source.java is full of them):
SourceFullException Indicates that the sink is temporarily full.
^^^^
Which is guaranteed to confuse people.
> > Would prefer StageManager. SilkServer is too much like "SilkServer(tm)"
> > and does not immediately associate with what it does.
>
> Names can be changed.
Then please change Source <-> Sink.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Blocks have discrete interfaces, which represent specific units of work.
If this is the difference between having a single handleEvent() method
and having a more do-this-stuff method name such as fetchMailForUser()
I see three cases:
1) Synchronous calls through discrete interface. The method creates an event
and enqueues it, then blocks until completion event is recieved or timeout.
2) Async call through discrete interface. As above, but without blocking.
3) Async call through Stage interface. The event is taken straight into
the Silk server.
Case 3 is for when you connect a Silk HTTP block with a Silk FileCache
block.
So, if we just see the block as a Stage (which it is), there shouldn't
be any problems.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Silk == More Seda Extractions
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
> Berin,
>
> always nice to see more of this - it is very interesting, although
> I must limit myself from throwing in remarks from the side. :)
I like comments, that's why I posted it.
>
>>to a Stage. Should the stage implement EventHandler, should the
>>configuration file manage the class to be invoked, or should there be a
>>getHandler() method?
>>
>
> Hmmm... As I understand it, the Stage maintains the thread pool for the
> event handler, and is in turn managed by the SilkServer.
Let me enlighten you :)
In Matt Welsh's implementation (which I have examined), the Manager takes
care of the Thread pool management for all stages. He has a couple of
implementations: ThreadPerProcessor model, and ThreadPoolPerSourcePerStage
model. Both have their advantages and disadvantages for different reasons.
The ThreadManager has threads whose sole responsibility in life are to
pop the QueueElements from the various Sinks, and push them onto the
correct EventHandler.
The Stage has no knowledge of ThreadManagement policies, nor should it.
The Only knows that it puts QueueElements on the various Sources that
are connected to it.
> Then a Stage has-a EventHandler. But I do not see that a Stage isa
> EventHandler. It may, but the responsibility of the stage is to manage
> the thread pool, and not to actually handle events.
That is the current relationship (i.e. has-a EventHandler). Actually you
have it wrong on the other statement. The responsibility of a Stage is to
process events--not to manage threads.
>>There are pros and cons to each method:
>>
>>* Stage extends EventHandler
>> - Really simple design.
>>
>
> I doubt this. Suppose I do
>
> class MyStage extends LeosStage
>
> and you
>
> class YourStage extends BerinsStage
>
> and LeosStage and BerinsStage are without a common base class.
>
> Suddenly, you have different ThreadPool implementations and
> the SilkServer has difficulties balancing the load over the
> system.
See above. All ThreadManagement is performed by the ThreadManager
for the system--NOT BY THE STAGE.
>> - Limits reuse (i.e. introspective event handlers)
>>
>
> I think the above problem is caused by this.
>
>
>> - Maintains IOC
>>
>
>
>>* Config file managed connection
>>
>
> Go for this. It appears to be the choice you have made below,
> and I think this is the best alternative.
>
>
>> - Easy to try new arrangements of EventHandlers and Stage
>>implementations.
>>
>
> This is, I think, the pattern Avalon configurations use. I think
> it can be applied here, too.
>
>
>>* getHandler() method
>>
>
> I don't see any advantages.
>
> My take on it:
>
> A Stage is to an EventHandler as a ComponentHandler is to a Component.
> A SilkServer is to a Stage as a ComponentManager is to a ComponentHandler.
:/
I get what you are trying to say, but the analogy is broken. A ComponentHandler
manages the creation policy of a Component. An EventHandler merely consumes
events. A Stage takes those events and either performs processing on them, or
generates new events based on its input. The analogy of a Stage to a Component
is fairly accurate though (in my interface a Stage IS a Component). Lastly,
a SilkServer is roughly akin to a ComponentManager in that you get a SourceMap
for a dissacosiated target Stage, just as a ComponentManager gives you an
implementation based on an interface. The difference is one of association.
>>Here is the list of intefaces I have already defined:
>>
>>
>>public interface Stage extends Component {
>> /**
>> * Sets the SourceMap for the Stage. This allows the stage
>>to specify
>> * exactly what Source we are feeding with events. The
>>SourceMap is set
>> * once, and only once during the life of the stage. Stages
>>are meant to
>> * be simple components, and the SourceMap is the last
>>method to be called
>> * during initialization.
>> */
>> void setSourceMap( SourceMap map );
>>}
>>
>
> Ummm... Isn't this backwards? This means that each stage chooses
> what sources to pull events from. Isn't this the responsibility
> of the SilkServer. A SinkMap makes more sense to me:
Keep in mind that the terms of Source and Sink are Queue-centric,
not Stage centric. Therefore we are choosing which Queue Source
we are pushing events onto. The ThreadManager manages what Queue
Sinks to pull information from.
>
> Sink thisIsWhereConnectionEventsGo = sinkMap.getSink
> ("silk.ConnectionEvent");
>
> not:
>
> Source thisIsWhereIPullEventsFrom = sourceMap.getSource
> ("silk.ConnectionEvent");
Source thisIsWhereConnectionEventsGo = sourceMap.getSource("silk.ConnectionEvent");
Queue-centric--remember that.
> Berin - as I wrote the above I just checked CVS. And in regards to your
> Source and
> Sink interfaces: To me, a Source is something that I take things from, and a
> Sink
> is where I put things in. You have Source.enqueue and Sink.dequeue. I see
> in front of me a lot of things (events) spewing out of the (kitchen) sink.
>
>
>>public interface SourceMap {
>>
>> /**
>> * This gets the main Source for the SourceMap. A SourceMap
>>must have at
>> * least one Source.
>> *
>> * @return the main <code>Source</code> for the SourceMap.
>> */
>> Source getMainSource();
>>
>
> I am against this. If you have a main source and a source map, you
> may run into aliasing problems (that is, what source is == main?).
The manager decides that. However, you may have multiple sources.
For instance, if we need a File's contents, and we have a CacheStage,
it would either return the File's contents, or it would generate
some events for the AsyncFileStage to get the file we need. We can't
very well have those events go to the main processing pipe, now can
we?
>
> Would prefer StageManager. SilkServer is too much like "SilkServer(tm)"
> and does not immediately associate with what it does.
Names can be changed.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Silk == More Seda Extractions
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Berin,
always nice to see more of this - it is very interesting, although
I must limit myself from throwing in remarks from the side. :)
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> The general concept is that a Stage consists of the Component
> itself (handles
> the logic of the stage), a group of input Sinks and one or more
> output Sinks.
> The SilkServer allows a Container to get a SourceMap for any
> stage that needs
> to be connected outside the system.
>
> My connundrum is trying to come up with a way to cleanly tie an
EventHandler
> to a Stage. Should the stage implement EventHandler, should the
> configuration file manage the class to be invoked, or should there be a
> getHandler() method?
Hmmm... As I understand it, the Stage maintains the thread pool for the
event handler, and is in turn managed by the SilkServer.
Then a Stage has-a EventHandler. But I do not see that a Stage isa
EventHandler. It may, but the responsibility of the stage is to manage
the thread pool, and not to actually handle events.
> There are pros and cons to each method:
>
> * Stage extends EventHandler
> - Really simple design.
I doubt this. Suppose I do
class MyStage extends LeosStage
and you
class YourStage extends BerinsStage
and LeosStage and BerinsStage are without a common base class.
Suddenly, you have different ThreadPool implementations and
the SilkServer has difficulties balancing the load over the
system.
> - Limits reuse (i.e. introspective event handlers)
I think the above problem is caused by this.
> - Maintains IOC
> * Config file managed connection
Go for this. It appears to be the choice you have made below,
and I think this is the best alternative.
> - Easy to try new arrangements of EventHandlers and Stage
> implementations.
This is, I think, the pattern Avalon configurations use. I think
it can be applied here, too.
> * getHandler() method
I don't see any advantages.
My take on it:
A Stage is to an EventHandler as a ComponentHandler is to a Component.
A SilkServer is to a Stage as a ComponentManager is to a ComponentHandler.
class StageImpl implements Stage
{
private EventHandler m_handler = null;
public void configure (Configuration config) throws
ConfigurationException {
m_handler = ClassUtils.loadClass (config.getAttribute ("class"));
}
/**
* Grab events and handle them.
*/
public void run () {
while ( shouldRun ) {
Signal signal = getEvent ();
// Do thread pool stuff
m_handler.handleEvent (event); // << Not like this - the thread
pool is used.
}
}
}
> Here is the list of intefaces I have already defined:
>
>
> public interface Stage extends Component {
> /**
> * Sets the SourceMap for the Stage. This allows the stage
> to specify
> * exactly what Source we are feeding with events. The
> SourceMap is set
> * once, and only once during the life of the stage. Stages
> are meant to
> * be simple components, and the SourceMap is the last
> method to be called
> * during initialization.
> */
> void setSourceMap( SourceMap map );
> }
Ummm... Isn't this backwards? This means that each stage chooses
what sources to pull events from. Isn't this the responsibility
of the SilkServer. A SinkMap makes more sense to me:
Sink thisIsWhereConnectionEventsGo = sinkMap.getSink
("silk.ConnectionEvent");
not:
Source thisIsWhereIPullEventsFrom = sourceMap.getSource
("silk.ConnectionEvent");
Berin - as I wrote the above I just checked CVS. And in regards to your
Source and
Sink interfaces: To me, a Source is something that I take things from, and a
Sink
is where I put things in. You have Source.enqueue and Sink.dequeue. I see
in front of me a lot of things (events) spewing out of the (kitchen) sink.
> public interface SourceMap {
>
> /**
> * This gets the main Source for the SourceMap. A SourceMap
> must have at
> * least one Source.
> *
> * @return the main <code>Source</code> for the SourceMap.
> */
> Source getMainSource();
I am against this. If you have a main source and a source map, you
may run into aliasing problems (that is, what source is == main?).
> /**
> * Get the named Source. If the SourceMap does not contain
> a match for the
> * name, the method throws an exception.
> *
> * @param name The name of the desired source
> *
> * @return Source the source associated with the name
> * @throws NoSuchSourceException if no source is associated
> with the name
> */
> Source getSource( String name )
> throws NoSuchSourceException;
Excellent.
> /**
> * The SourceArray allows the Stage to get an array of all
> Sources attached
> * to the stage.
> *
> * @return an array of <code>Source</code> objects. There
> is at least one
> * Source in the array.
> */
> Source[] getSourceArray();
> }
>
> public interface SilkServer {
Would prefer StageManager. SilkServer is too much like "SilkServer(tm)"
and does not immediately associate with what it does.
> /**
> * Gets the source for a specified stage name.
> */
> SourceMap getSourceMap( String stageName );
> }
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>