On Tue, 18 Dec 2001, Berin Loritsch wrote: > giacomo wrote: > > > 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). > > > This is more for asynchronous command signals that are used to manage the > cache and other background systems. It will also be used to drive the > ActiveMonitor as well as database connection testing, removing dead weight > from the cache, regenerate XSP/Sitemap objects, etc.
I thought that is is sort of those things but wasn't sure enough. > A command queue works to allow one or two management threads to perform > all management work in Cocoon. It can also drive asyncronous initialization > events (like the beginning lifecycle for all the components). That way > all management and initialization does not affect the direct run-time of > using Components. The DataSources code will be made quicker due to the > fact that we won't have to call the "db ping" query prior to returning the > connection. Ok. > Another thing that will help is the profiler/instrumentation that we are > developing for the next version of Excalibur. This is a way that the > StatusGenerator would be able to get pool size information and max pool > sizes, etc. I've seen this on the valond list. Cool beans :) Thanks, Giacomo > > > > > > 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] > > > > . > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
