cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Froehlich" <>
Subject RE: Adding Resource Monitor to Generators
Date Mon, 10 Dec 2001 17:03:57 GMT
>From: Berin Loritsch []
>Sylvain Wallez wrote:
>> Berin Loritsch a écrit :
>>>Sylvain Wallez wrote:
>> <snip/>
>>>>But here's another use case : suppose you have a portal site where 10%
>>>>of the pages make 90% of the requests, but where 100% of the pages are
>>>>monitored, because they have been visited at least once since server
>>>>startup. I'm not good at statistics, but lets suppose this results in
>>>>only 15% of all pages to be requested in a monitor scan period.
>>>>This means that at each refresh period, ActiveMonitor will scan 100% of
>>>>the pages when only 15% are really needed to be scanned : 85% of useless
>>>>File.getLastModified() !! This is what I wanted to point out.
>>>My concept of how to use Monitor was to monitor things that require
>>>action.  This means that XSP and Sitemap files should be monitored--their
>>>change requires action by the system.  Cached resources must be monitored,
>>>as they affect the validity of the cache.  The action I foresee for this
>>>event is to invalidate the cache entry and release the Resource.
>>>This way only the pages that are required to be monitored are monitored.
>>>As to the 85% useless File.getLastModified(), you have to consider the
>>>cost of the action.  If you have that many resources that you have not
>>>removed your Resource entry, then there is something wrong in the way
>>>you are using it.  Also, if this is happening in a background thread
>>>at low priority (read asynchronously that will not override actual
>>>serving of requests), then the cost of these extraneous calls are lowered!
>> OK I think to have understood now (light bulb over my head;) : do you
>> mean that once a Resource has been detected as modified, we should
>> remove it from the monitor and release the associated data, i.e. remove
>> the cache entry or unload the XSP-generated class ? This makes sense,
>> now.
>Yes.  But please note that for the ProgramGenerator you may want to keep
>the Resource in the monitor--unless the Resource was deleted.  That way,
>once the XSP/Sitemap has been found to have been changed,  The
>ProgramGenerator regenerates the resource in question--thus still needing
>to know if it changed again.

But AIUI same for the Cache. When a Cache entry is requested and invalid
through his TimeStampCacheValidity the Resource is keept in the Monitor.
The only limitation of the size of the Monitor are the *real* available
Resources. Once they are in the Monitor they are never removed. Can we
handle this somehow? Is this maybe a part of the Resource himself to remove
an entry when i.e. the Resource disappeared somehow?

Or did I missed the point here?

>> One more question : don't you think a kind of Resource time-to-live can
>> be useful, i.e. automatically invalidate resources that haven't been
>> used for a long time ? This would allow to purge infrequently used
>> resources from the system. Or maybe this should be handled by the MRU
>> policy of the cache.
>I would rather have that handled by the Cache system.  I want to avoid
>undue complexity in the Monitor system (in fact I am thinking of some

Yupp that is already handled by the Cache System (CachingxxxPipelins). The
MRUMemoryStore is really dumb in this case and idependent from the underlying
Cache system.



"Horngren's Observation (generalized): The real world is a special case."

To unsubscribe, e-mail:
For additional commands, email:

View raw message