Return-Path: 
 <dev-return-22756-apmail-forrest-dev-archive=forrest.apache.org@forrest.apache.org>
Delivered-To: apmail-forrest-dev-archive@www.apache.org
Received: (qmail 16543 invoked from network); 17 Feb 2006 11:27:33 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 17 Feb 2006 11:27:33 -0000
Received: (qmail 1521 invoked by uid 500); 17 Feb 2006 11:27:33 -0000
Delivered-To: apmail-forrest-dev-archive@forrest.apache.org
Received: (qmail 1500 invoked by uid 500); 17 Feb 2006 11:27:32 -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 1489 invoked by uid 99); 17 Feb 2006 11:27:32 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Feb 2006 03:27:32 -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; Fri, 17 Feb 2006 03:27:31 -0800
Received: from [82.69.78.226] (helo=[192.168.0.2])
	by pythagoras.zen.co.uk with esmtp (Exim 4.30)
	id 1FA3lW-000103-C4
	for dev@forrest.apache.org; Fri, 17 Feb 2006 11:27:10 +0000
Message-ID: <43F5B30C.1060606@apache.org>
Date: Fri, 17 Feb 2006 11:27:08 +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>
 <499888440602150918v6eb79d57xb629ef19ed9f6a11@mail.gmail.com>
In-Reply-To: <499888440602150918v6eb79d57xb629ef19ed9f6a11@mail.gmail.com>
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

I'll come back to this in about a week - other things have taken priory 
right now.

In general I agree with your comments and will commit something ASAP.

Ross

Tim Williams wrote:
> On 2/15/06, Ross Gardler <rgardler@apache.org> 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.
> 
> 
> By "handled" I gather you mean created and ran through the lifecycle. 
> This is a result of our implementing the locationmap grammar "inline".
>  In other words, we don't have a grammar and a treeprocessor with
> differentiation between nodes/nodebuilders.  Each node is responsible
> for building and instantiating its allowable child nodes.  When I
> first started looking into this stuff I considered whether a more
> robust approach (a la sitemap) should be taken or not but was
> [probably rightly] put off [1].  I suspect that you're seeing what I
> saw when I wrote that email.
> 
> 
>>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.
> 
> 
> I think any solution is going to "seem" hacky.  Cocoon has the benefit
> of a TreeProcessor which does most of the heavy lifting for it.
> 
> 
>>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.
> 
> 
> Ok, we should at least comment on this in the source so that if we
> ever run into memory issues we know where to look.  For example,
> without ?Ron? looking into our current memory consumption, it would
> have taken some time to find that the XmlFileModule is the culprit.
> 
> 
>>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).
> 
> 
> How can we control it from forrest.properties?  Right now, it requires
> a restart and it's either on or off in forrest.xconf.
> 
> --tim
> 
> 
> [1] - http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112112847425768&w=2
> 
>