[infinispan-dev] Exposing transient/mortality information externally

Galder Zamarreno galder at redhat.com
Thu Nov 26 04:16:42 EST 2009


Hi,

Re: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267469#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.

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



More information about the infinispan-dev mailing list