Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: WildcardMatcherHelper caching issue
Date: Mon, 8 Jan 2007 11:52:18 +0100
Message-ID: <A955EA1F8FE31749AEC8C998082F6C7C010CD928@hai01.hippo.local>
Thread-Topic: WildcardMatcherHelper caching issue
Thread-Index: AcczEkT7v/wT1W1LTmygDPyeHBMv1QAAHpgA
From: "Ard Schrijvers" <a.schrijvers@hippo.nl>
To: <dev@cocoon.apache.org>


> Ard,
>=20
> What is cached is the pattern, not the string to be matched=20
> 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

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