[infinispan-dev] Exposing transient/mortality information externally

[Manik Surtani]

On 30 Nov 2009, at 21:49, Brian Stansberry wrote:

> Be cautious about exposing cache contents (even just keys) via JMX. If 
> you do, make it something that people can turn off, without turning off 
> the basic JMX interface. Reason is the same as in recent discussions 
> about providing access to the cache itself via JMX. People who deploy a 
> JMX-enabled cache are not necessarily expecting that any code that can 
> access the MBean server can also inspect cache contents. For example, a 
> simple session id string is a likely key, and session ids are 
> essentially a security token that shouldn't be exposed willy-nilly.
> 
> In general, for the Hibernate 2LC use case, IMHO it's better if the 
> Hibernate statistics API is improved, rather than having people access 
> the cache directly.

+100

> How the data is stored in the cache should be an 
> internal implementation detail that can be changed when needed. That's 
> part of why your addition of eviction configuration to Hibernate 
> Configuration properties was so nice.
> 
> All that said, if information like
> 
>> [Person#1:[created:123456,lifespan:120000,maxIdle:60000,lasUsed:13456],
>> Person#2:[created:234567,lifespan:120000,maxIdle:60000,lasUsed:24567],
>> ...]
> 
> is readily available internally, having a mechanism for authorized users 
> to get at it sounds pretty cool. :-)

Cool, but still though, that should be a Hibernate Statistics API.

> 
> 
> On 11/26/2009 03: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.
>> 
>> 
>> 
>> 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,
> 
> 
> -- 
> Brian Stansberry
> Lead, AS Clustering
> JBoss by Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org