cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Gianni <simo...@apache.org>
Subject Re: [c3 monitoring] Cache overview
Date Wed, 15 Jul 2009 18:43:56 GMT
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.
- 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 ?
>
>   


-- 
Simone Gianni            CEO Semeru s.r.l.           Apache Committer
http://www.simonegianni.it/


Mime
View raw message