[hibernate-dev] [infinispan-dev] Exposing transient/mortality information externally

[Galder Zamarreno]

FYI

On 11/26/2009 10:16 AM, Galder Zamarreno wrote:
> 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