cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <>
Subject Re: [c3 monitoring] Cache overview
Date Fri, 17 Jul 2009 05:16:11 GMT
Dariusz Łuksza wrote:
> On Wed, Jul 15, 2009 at 8:43 PM, Simone Gianni<> wrote:
>> Hi Dariusz,
>> I had a look at your patch. I see the method "listKeys", with the
>> description "Removes all cached data". I think this is an error, looking at
>> the source it lists cache key names, and does not remove them, while the
>> "clear" method does that.
> Strange that I've missed that ...
>> Apart from this small error, regarding your question, I'm trying to figure
>> out what a user will want to see when checking the cache.
>> I'm brainstorming here, trying to paint a big picture, probably the real
>> features will be much smaller, but this could provide you ideas and at the
>> same time help identify which ones are most important.
>> I can think of three possible scenarios :
>> - While developing, they see something they don't expect to see, and they go
>> check if there is some cached data in the way.
>> - While optimizing the application, they go check what happens in the cache,
>> if/how they are wasting RAM by caching too much or wasting CPU by not
>> caching enough.
>> - At runtime, they could access it to see what's going wrong, to recover
>> some ram, to clear everything if they just published something really
>> important and they want it to appear now.
>> Given these three scenarios, these are things that may be useful to see via
>> JMX, but I don't know which of them are actually achievable or already
>> there, so this is an "abstract" POV :
>> - The component that stored that entry (it's part of the name already for
>> ComponentCacheKey)
>> - Which "pipeline" I'm referring to, so that if it's not working properly I
>> can check if there is cached stuff.
>> - The size of the entry, I see it is possible to obtain it from CacheKey
>> with your patch. this is useful if I'm profiling or in desperate need to
>> free some ram.
>> - When that entry will expire by itself, if it will.
>> - Last time that entry has been used (red) from the cache, if ever.
> Here you generally refer to single cache entry. But question how to
> represent cache entry on JMX tree is still actual. I have two ideas
> how we can do that:
> - based on URL with they published
> - based on pipeline and type of cache

Just one quick comment for now (I'll get back to you with more thoughts
at the weekend but the discussions already goes into the right direction
Does this still work if you have thousands or tens of thousands cache


Reinhard Pötz                           Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member        

View raw message