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/
