cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <a.schrijv...@hippo.nl>
Subject RE: WildcardMatcherHelper caching issue
Date Mon, 08 Jan 2007 10:52:18 GMT

> Ard,
> 
> What is cached is the pattern, not the string to be matched 
> against it,
> so what you describe isn't a problem IIUC.

I already was a little amazed. But then, who is using always-changing patterns? Like in dynamic
sitemaps or something? Do not really see this possible memory leak in here..

Ard

> 
> On Mon, 2007-01-08 at 10:30 +0100, Ard Schrijvers wrote:
> > Hello,
> > 
> > think I kind of missed this WildcardMatcherHelper untill 
> now. From which cocoon version on is this available? Can you 
> define in your matcher wether it should use this 
> WildcardMatcherHelper, or is this by default?
> > 
> > Regarding the caching, currently it would seem to me like a 
> very possible memory leak. What if I have something like
> > 
> > <map:part element="othermatcher" 
> value="cocoon://foo/{date:yyyyMMddHHmmssSS}"/>
> > 
> > or if you have an active forum build with cforms, and 
> 2ervw3verv452345435wdfwfw.continue patterns are cached (or is 
> it only for caching pipelines?)
> > 
> > This would imply a new cached pattern for every request. Of 
> course, the thing above with the date is stupid, but it is 
> too easy to  create memory leaks for a user. The solution 
> that a user should choose between caching or noncaching 
> WildcardMatcherHelper seems to me to difficult for an average 
> user to make a judgement on this. The option about a 
> WeakHashMap should be some sort of SoftHashMap (SoftRef) 
> instead. WeakReferences are deleted when no longer a strong 
> ref is available, so either there would be a strong ref 
> (implying the same memory leak) or there whould be no strong 
> ref, so all cached patterns are removed on every gc. With 
> SoftReferences they are only removed when jvm decides to do 
> so (when low on memory). But, IMO, it is not ok to have the 
> jvm possibly go low on memory, and the jvm to remove cached 
> patterns at random (more sense it makes, to have the most 
> used patterns kept in memory). 
> > 
> > I really think the best way is some simple LRUMemoryStore 
> with a maxitems configured by default to 1000 or something, 
> and possibly overridden for the user who knows more about it. 
> Default, every user can easily work with it without having to 
> think about it. 
> > 
> > Regards Ard
> 
> -- 
> Bruno Dumon                             http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> bruno@outerthought.org                          bruno@apache.org
> 
> 

Mime
View raw message