On 26 Nov 2009, at 09:16, Galder Zamarreno wrote:
Hi,
Re:
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267469#...
I think Brian has a good point here. We don't expose any internal
information wrt each cache entry's expiry/eviction values. Brian has a
good point that this could guide him in finding out which entries have
been last been used, how long they've been in memory and how it could
tweak expiration/eviction accordingly.
If we don't do anything, I think we run the risk of people being forced
to get hold of the container, looping through it and getting information
that they need from inspecting internal classes.
So, I'd suggest that we add a JMX method to CacheDelegate called
something like:
Map<String, Map<String, long>> getTransientAndMortalityInformation().
(I'm open to suggestions to other names. This is the 1st thing that came
to my mind)
This would return a Map where the key is the toString form of the cache
key and the value part is a map where individual transient/mortal
properties are returned. I.e.
[Person#1:[created:123456,lifespan:120000,maxIdle:60000,lasUsed:13456],
Person#2:[created:234567,lifespan:120000,maxIdle:60000,lasUsed:24567],
...]
We could event add calculated properties such as 'age' which is current
- created. This would vary with each call obviously.
Surely that would be hugely expensive? To iterate through the entire collection? And
what when you have JOPR polling this value every 5 seconds or something? ;)
As indicated in the forum entry, at least based on this use case, I
don't see an immediate need to query this type of information given a
key, although could be potentially useful for other use cases. The
reason this would not help much right now is because it is Hibernate
that creates the keys of 2nd level cache (i.e. CacheKey) and these are
nor meant to be recreated externally, so it'd be hard for external apps
to get something out of the Infinispan cache directly without going
through the Hibernate integration layer.
My suggested JMX method could allow for individual transient/mortality
information to be queried by tools, or other client jmx code. Maybe some
tools could use that to create a table or something like that which
could be ordered based on a column? i.e. age. Also, tools or client jmx
code could convert those longs into whatever they want: seconds,
minutes...etc
The reason I think JMX is a good candidate here is this is inherently
monitoring information and it allows us to expose internal information
via primitives without having to expose internal classes.
Thoughts?
Cheers,
--
Galder ZamarreƱo
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org