You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Gerhard Froehlich <g-...@gmx.de> on 2001/12/05 15:48:08 UTC
re-send Excalibur ActiveMonitor
Hi,
uninteresting, misspelled, needless or
just overseen?
Cheers
Gerhard
"EARTH FIRST! We'll strip-mine the other planets later."
>-----Original Message-----
>From: Gerhard Froehlich [mailto:g-froehlich@gmx.de]
>Sent: Sunday, December 02, 2001 2:06 PM
>To: cocoon-Dev
>Subject: Excalibur ActiveMonitor
>
>
>Hi,
>I think we need to implement the ActiveMonitor
>in the Cocoon Project, to increase the performance
>of Cocoon.
>(I place the mail here in the Cocoon list,
>because it's a Cocoon related topic. But if it's the
>wrong place, I have no problem to move this thread
>into Avalon dev list.)
>
>Berin suggested in the mail:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=99857216131771&w=2
>that instead of calling ${file}.lastModified() we asking the
>Excalibur ActiveMonitor if the resource has changed or not.
><Berin>
>"Each resource in the collection of resources is tested on a
>frequency you specify (i.e. 1/minute, 1/half-hour, etc).
>That way during extreme load conditions the number of times we
>call the "lastModified" method doesn't change. Instead of 1/request
>(with 200 simultaneous users requesting 4 pages a second
>that comes to 800 calls a second) it is once per period of time."
></Berin>
>
>I can't implement this ActiveMonitor from scratch, because
>I have less knowledge of Cocoon internals (was alway in the
>backend ;). So:
>Where is the right place to implement this ActiveMonitor and
>how would you proceed?
>
>Cheers
>Gerhard
>
>--------------------------------------------
>black holes are when GOD is dividing by zero
>23 49 43 51 3A 20 31 32 33 35 33 34 38 31 31
>--------------------------------------------
>
>
>---------------------------------------------------------------------
>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
Re: re-send Excalibur ActiveMonitor
Posted by Berin Loritsch <bl...@apache.org>.
Gerhard Froehlich wrote:
> Hi,
> Ok dived into the code:
>
> I identified 2 places which IMHO the
> ActiveMonitor could be placed:
>
> Source (SitemapSource,URLSource)
> and Reader (ResourceReader)
>
> But a) I only have a vague imagining what
> this classes are doing and b) maybe there
> are some other places!
>
> Ideas, Suggestion?
Here is a rough overview of ActiveMonitor and it's cousin PassiveMonitor:
The Monitor keeps track of changes to a Resource. It's purpose is to
notify a PropertyEventListener when the Resource is changed. The
PassiveMonitor is used in closed systems where the Resource is not going
to be changed by a third party. In this manner, it is like the publish/
subscribe pattern. The PropertyEventListener is registered with the
Monitor which in turn registers it with the Resource. The PropertyEventListener
is in essence the Subscriber, and the Resource is in essence the
Publisher.
The Monitor provides a central management point for Resources, as well
as the opportunity for a Monitor to provide a worker thread that will
perform periodic checks. More on that Later.
Right now, we have the following classes:
Monitor -- the interface for the component.
Resource -- an abstract class that takes care of the notifications
StreamResource -- an abstract specialization of Resource that manages
Resources that represent IO stream information.
After the StreamResource is written to, it notifies
all the listeners that it has changed.
FileResource -- a concrete specialization of the StreamResource that
manages files.
PassiveMonitor -- The passive monitor does not provide any background
thread to poll the resources. It relies on the
resources themselves to propogate the change notifications.
It is only really effective in situations where the
resource will never be altered outside the closed
environment of the server. Clearly this assumption
does not hold true for FileResources or distributed
environments.
ActiveMonitor -- The active monitor does everything the passive monitor
does, but it also provides a background thread that
polls the Resources that the monitor is monitoring
periodically. If a resource is changed, the background
thread will tell the Resource to propogate the change.
The Resource concept was originally derived from the Source object, but
addresses bi-directional semantics. It's best used for any system that
has mutable sources. The conceptual changes will mean that the Cache,
the ProgramGenerator, and the configuration files never explicitly check
if the resource is up to date. Instead, it provides a PropertyChangeListener
to listen for events when the Resource has been altered.
This is a very important concept to grasp. It is analogous to the change
from a DOM based system to a SAX based system. You are changing from a
request/response model for up-to-date checks to an event based model.
The Seda project (link previously posted in the "Rethinking the Finite
State Machine Approach to Flowmaps" thread) has very impressive results.
Basically a finite number of threads (in this case one) can provide
profound impact on the performance of a system.
Back to how to use the Monitor components.
The configuration for the Monitors (both active and passive) is essentially
the same--with the only difference being the parameter that specifies how
often we poll the Resources. Here is a snippet:
<role name="org.apache.avalon.excalibur.monitor.Monitor"
shorthand="monitor"
default-class="org.apache.avalon.excalibur.monitor.ActiveMonitor"/>
<monitor>
<thread priority="5" frequency="60000"/>
<init-resources>
<!-- This entry can be repeated for every resource you want to register immediately -->
<resource key="file:./myfile.html" class="org.apache.avalon.excalibur.monitor.FileResource"/>;
</init-resources>
</monitor>
What this does is it initializes the ActiveMonitor, and sets the polling thread
to priority 5 with a frequency of once a minute (1000ms * 60s = 1m). This is
usually good for a development system--but a production system may want to lengthen
the time between checks. In this example the resource identified by the key
"file:./myfile.html" is initialized (without any listeners).
Now to the run time system:
public interface Monitor
{
String ROLE = "org.apache.avalon.excalibur.monitor.Monitor";
/**
* Add a resource to monitor. The resource key referenced in the other
* interfaces is derived from the resource object.
*/
void addResource( Resource resource );
/**
* Find a monitored resource. If no resource is available, return null
*/
Resource getResource( String key );
/**
* Remove a monitored resource by key.
*/
void removeResource( String key );
/**
* Remove a monitored resource by reference.
*/
void removeResource( Resource resource );
}
If you want to add a resource, you generally do something like the following:
FileResource file = new FileResource( path );
file.addPropertyChangeListener( this ); // assuming the "this" is a PropertyChangeListener
monitor.addResource( file );
Now, your class will be notified. But what if we are already monitoring a Resource?
in that case I suggest you do this:
Resource file = monitor.getResource( path );
file.addPropertyChangeListener( this );
The removeResource() options operate as you would expect.
Now what happens when you add a resource that is a duplicate?
The Monitor implementation checks for this, and copies all the PropertyChangeListeners
from the Resource that you added to the existing Resource.
Hopefully this overview sparks your imaginations. Also, if you have suggestions
for making it better, let me know.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: re-send Excalibur ActiveMonitor
Posted by Gerhard Froehlich <g-...@gmx.de>.
Hi,
Ok dived into the code:
I identified 2 places which IMHO the
ActiveMonitor could be placed:
Source (SitemapSource,URLSource)
and Reader (ResourceReader)
But a) I only have a vague imagining what
this classes are doing and b) maybe there
are some other places!
Ideas, Suggestion?
Cheers
Gerhard
---------------------------------
Never share a foxhole with anyone
braver than you are.
---------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: re-send Excalibur ActiveMonitor
Posted by Per-Olof Norén <pe...@alma.nu>.
----- Original Message -----
From: "Gerhard Froehlich" <g-...@gmx.de>
To: "cocoon-Dev" <co...@xml.apache.org>
Sent: Wednesday, December 05, 2001 3:48 PM
Subject: re-send Excalibur ActiveMonitor
> Hi,
> uninteresting, misspelled, needless or
> just overseen?
I Saw it, Liked it, Waiting for it. :-)
Performance is going to be the nr one issue for choosing cocoon in the end.
A powerful tool/framework that can´t scale isn´t going to be found in all
the places
where it should be. Still, I don´t really know where to put it :-)
/ Per-Olof
>
> Cheers
> Gerhard
>
> "EARTH FIRST! We'll strip-mine the other planets later."
>
> >-----Original Message-----
> >From: Gerhard Froehlich [mailto:g-froehlich@gmx.de]
> >Sent: Sunday, December 02, 2001 2:06 PM
> >To: cocoon-Dev
> >Subject: Excalibur ActiveMonitor
> >
> >
> >Hi,
> >I think we need to implement the ActiveMonitor
> >in the Cocoon Project, to increase the performance
> >of Cocoon.
> >(I place the mail here in the Cocoon list,
> >because it's a Cocoon related topic. But if it's the
> >wrong place, I have no problem to move this thread
> >into Avalon dev list.)
> >
> >Berin suggested in the mail:
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=99857216131771&w=2
> >that instead of calling ${file}.lastModified() we asking the
> >Excalibur ActiveMonitor if the resource has changed or not.
> ><Berin>
> >"Each resource in the collection of resources is tested on a
> >frequency you specify (i.e. 1/minute, 1/half-hour, etc).
> >That way during extreme load conditions the number of times we
> >call the "lastModified" method doesn't change. Instead of 1/request
> >(with 200 simultaneous users requesting 4 pages a second
> >that comes to 800 calls a second) it is once per period of time."
> ></Berin>
> >
> >I can't implement this ActiveMonitor from scratch, because
> >I have less knowledge of Cocoon internals (was alway in the
> >backend ;). So:
> >Where is the right place to implement this ActiveMonitor and
> >how would you proceed?
> >
> >Cheers
> >Gerhard
> >
> >--------------------------------------------
> >black holes are when GOD is dividing by zero
> >23 49 43 51 3A 20 31 32 33 35 33 34 38 31 31
> >--------------------------------------------
> >
> >
> >---------------------------------------------------------------------
> >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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org