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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
