cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Froehlich" <g-froehl...@gmx.de>
Subject RE: Adding Resource Monitor to Generators
Date Mon, 10 Dec 2001 17:03:57 GMT
>From: Berin Loritsch [mailto:bloritsch@apache.org]
>
>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
>simplifications).

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.

<snip/>

  Gerhard

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



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


Mime
View raw message