cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: [RT] This is what I am proposing for Excalibur that would be great for Cocoon
Date Tue, 18 Dec 2001 21:00:27 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> > .
> >
> >
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message