cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <reinh...@apache.org>
Subject Re: [c3 monitoring] Cache overview
Date Tue, 21 Jul 2009 11:03:37 GMT
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.
> 
> 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.

In Cocoon 2.x, a pipeline can have and ID attribute. For the purpose of
drilling down caching entries we could introduce it in 3.0 too. (I've
always wondered about the use case for pipeline ids ...)

Reinhard

> - 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.
> 
> Since the cache could contain quite a number of elements, there should
> be a way to isolate keys matching certain criteria. It would be nice to
> pack everything in the name, but all this stuff will not fit in the
> "name", and it is used then as a key for other operations.
> 
> .. these are some random ideas :
> - "String getKeyInfo(String keyname)" method, returning all possible
> data about that key as a plain string. Simple to implement, but may be
> tedious to use (call this method once for each key to see it's data).
> - "String[] queryCache(long minsize, Date mintime .......)", matching a
> criteria based on two or three parameters
> - "String[] queryInfo(long minsize, Date mintime .......)", same as
> before, but returns directly the info
> - "boolean clear(long minsize, Date mintime .......)", clean using the
> given criteria
> - you can easily vary on this theme :)
> 
> Hope it helps,
> Simone
> 
> 
> 
> Dariusz Łuksza wrote:
>> Hi,
>>
>> As you all ready notice, I think, I've created issue in Jira and
>> attach patch that covers some basic features of this milestone.
>>
>> Now I wondering how to present on JMX tree of CacheKeys that it would
>> be usable and readable for users, what data and informations should
>> apear in this tree ? Maybe you have some ideas ?
>>
>>   
> 
> 


-- 
Reinhard Pötz                           Managing Director, {Indoqa} GmbH
                         http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@apache.org
________________________________________________________________________

Mime
View raw message