Return-Path: 
 <dev-return-22747-apmail-forrest-dev-archive=forrest.apache.org@forrest.apache.org>
Delivered-To: apmail-forrest-dev-archive@www.apache.org
Received: (qmail 36927 invoked from network); 15 Feb 2006 16:12:34 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 15 Feb 2006 16:12:34 -0000
Received: (qmail 68318 invoked by uid 500); 15 Feb 2006 16:12:33 -0000
Delivered-To: apmail-forrest-dev-archive@forrest.apache.org
Received: (qmail 68280 invoked by uid 500); 15 Feb 2006 16:12:33 -0000
Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@forrest.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@forrest.apache.org>
List-Post: <mailto:dev@forrest.apache.org>
Reply-To: dev@forrest.apache.org
List-Id: <dev.forrest.apache.org>
Delivered-To: mailing list dev@forrest.apache.org
Received: (qmail 68268 invoked by uid 99); 15 Feb 2006 16:12:33 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Feb 2006 08:12:33 -0800
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Received: from [212.23.3.140] (HELO pythagoras.zen.co.uk) (212.23.3.140)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Feb 2006 08:12:32 -0800
Received: from [82.69.78.226] (helo=[192.168.0.2])
	by pythagoras.zen.co.uk with esmtp (Exim 4.30)
	id 1F9PGE-0008E4-Le
	for dev@forrest.apache.org; Wed, 15 Feb 2006 16:12:10 +0000
Message-ID: <43F352CD.2030101@apache.org>
Date: Wed, 15 Feb 2006 16:11:57 +0000
From: Ross Gardler <rgardler@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: more on locationmap caching
References: <499888440602101717r65d8b650ha6f35e05a4959cfc@mail.gmail.com>
 <499888440602141853g366e9a38y2f58035d7279bd15@mail.gmail.com>
 <43F3395C.1010905@apache.org>
In-Reply-To: <43F3395C.1010905@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-Pythagoras-IP: [82.69.78.226]
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Ross Gardler wrote:
> Tim Williams wrote:
> 
>> On 2/10/06, Tim Williams <williamstw@gmail.com> wrote:
>>
>>> It seems to me that implementing CacheableProcessingComponent with an
>>> input module like LM isn't feasible since there's only one instance of
>>> it and it won't help us cache at the more granular level.  I think I
>>> confirmed that by following it through it's lifecycle this evening.
>>>
>>> Anyway, Ross is on to correcting the validity issue so I thought I'd
>>> spend some time on figuring out how to get away from our
>>> homegrown-hashmap-cache.  I think instead of trying to use the cocoon
>>> cache, the answer is to manage validity ourselves and go directly to
>>> the store.    This gets our little lm cache "managed" with the real
>>> cocoon store as i think it should be.
>>>
>>> The only problem that I can foresee is our current transient store is 
>>> set with:
>>>
>>> <parameter name="maxobjects" value="100"/>
>>>
>>> 100 seems extremely small to me anyway but I think if we started to
>>> use it for the lm, we'd find that it's definitely too small and would
>>> spend as much resources cleaning itself as to make it not worth it.
>>> Anyone know why it shouldn't be larger?
>>>
>>> Does storing lm cached hints in the transient store seem reasonable?
>>>
>>> Thanks,
>>> --tim
>>
>>
>>
>>
>> FYI. I'm not very keen on implementing it yet, but we may be forced to
>> decide just how important this is to us.  We'll see if I get any other
>> responses, but I'm not holding my breath...
>>
>> http://marc.theaimsgroup.com/?t=113995323300001&r=1&w=2
> 
> 
> Thanks for following through Tim.
> 
> I've been looking at the use of MultiSourceValidity. It's not trivial 
> unfortunately. The way mounted sitemaps are handled is causing problems 
> (simply put they are handled differently depending on whether they are 
> in a select or not). We need to refactor the handling of mounted 
> locationmaps.

That should read "the way mounted *locationmaps* are handled". This is a 
Forrest issue, not a Cocoon one.

Ross

> I've got a solution, but it seems "hacky". I want to find the time to 
> look at how Cocoon handles mounted sitemaps and see if we can learn from 
> that.
> 
> With respect to the use of Cocoons store Vs. our current home grown 
> solution. I think it is unlikely that we will hit the memory limits 
> within the locationmap. The items we are storing are small (strings) and 
> the number is relatively low. Even in a very large site it is unlikely 
> to go beyond a few thousand items.
> 
> If it becomes a problem we can reconsider.
> 
> Speaking personally, I need the ability to invalidate the locationmap 
> tree when any of the mounted maps are changed. The move to 
> MultiSourceValidity will solve this problem. I'm not too concerned right 
> now about being able to control the locationmap cache from within the 
> sitemap, as long as we can control it from forrest.properties (which we 
> already can).
> 
> Ross
> 
>