forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: more on locationmap caching
Date Sat, 11 Feb 2006 03:24:47 GMT
Tim Williams 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?

We have many Cocoon defaults that need to be investigated
and fine-tuned. I think that we already have a Jira issue
for that. There are some cache tuning docs at Cocoon or
in their Wiki.

We should first re-compare our settings with cocoon-2.2
I see that we have some comments mixed up in our
WEB-INF/xconf/forrest-core.xconf so perhaps we have
some parameters out-of-sync too.

Now that we have the serverStatus plugin we can start to
refine our settings.

> Does storing lm cached hints in the transient store seem reasonable?

Using the stores in general sounds great. 


View raw message