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