[hibernate-dev] [infinispan-dev] Exposing transient/mortality information externally
Manik Surtani
manik at jboss.org
Tue Dec 1 04:29:57 EST 2009
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
More information about the hibernate-dev
mailing list