On Tue, 11 Dec 2001, Berin Loritsch wrote: So far it seems a good way to manage events. I have to confess that I will have to read it again in some days as it is very abstract to me for now. But can you quickly explain in which part of Cocoon it will help (sorry, but I havn't got where you'd like to put this in the Cocoon system).
Giacomo > NOTE: I proposed this to Avalon team today, and it would be what feeds the > ActiveMonitor, PoolController events, etc. It allows a finite number > of threads to ensure the maintenance aspects of the pools, etc; while > minimizing the critical path execution times. > > I would like to propose a new scratchpad component to help with management > and maintenance tasks that should be performed asynchronously from the > main program flow. > > While I do want to base a similar approach to SEDA in Avalon, I think it > would be better served by defining the concept of EventQueues in Excalibur, > with full fledged Stages defined in CornerStone. This will change the > way we think about some problems, but that's a good thing. > > The full Staged Event-Driven Architecture assembles a pipeline of Stages. > These Stages contain one or more Sources, and one or more Sinks. Both > the Sources and Sinks are Queues, and consist of QueueElements. The Stage > is wrapped by the system to associate an EventHandler and a ThreadManager. > > In ASCII art, a single stage is something (conceptually) like this: > > +--------------------------------------------+ > | StageWrapper | > | | > | +--------+ +-----------+ +------------+ | > | | Source | | Stage | |EventHandler| | > | +--------+ | | +------------+ | > | | +-------+ | | > | +--------+ | | Sink | | | > | | Source | | +-------+ | +-------------+ | > | +--------+ | | |ThreadManager| | > | +-----------+ +-------------+ | > +--------------------------------------------+ > > The application is built on Stages and associated EventHandlers. For instance, > the EventHandler would have a reference to the Stage, and forward events to the > actual stage logic. The Stage's responsibility is to act on those events, and > send new events to the various Sinks in it's responsibility. > > With the exception of the getWrapper() method, Matt Welsh did a good job of > conceptualizing SEDA with Inversion of Control principles. > > The ThreadManager's responsibility is to both manage the thread creation policies, > but also pull the events from the Source queue, and send them to the EventHandler. > There are two different types of EventHandlers: regular (ThreadSafe) and >SingleThreaded. > We already express these differences with our interfaces, so using the specialized > interface is not needed. > > What I want to do for Excalibur is to take the concept of an EventQueue (Source > or Sink is not necessary at this time) and have it controlled by a ThreadManager > going to an EventHandler. > > In essence, I am proposing everything inside the StageWrapper for Excalibur > and the Stage and purpose-specific queues for Cornerstone. > > For Excalibur, it would provide a nice way of performing asynchronous maintenance > commands on all the Excalibur Components. In the absence of the event queues, > all the Components would be unchanging, or at the very least blocking for management > events. > > This does follow IoC, and makes the perceived performance of the system faster > under high load. We will have to have a method of adding events to the CommandQueue. > > The Queue hierarchy I would like to see in the end: > > EventQueue (Basic mechanics) > CommandQueue (Contains a queue of maintenance commands--some repeatable events, some > run once) > Source (In Cornerstone) > Sink (In CornerStone) > > The Source and Sink queues should not contain repeatable events, as they are only >needed > for the CommandQueue. > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
