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

[Galder Zamarreno]

On 12/01/2009 10:29 AM, Manik Surtani wrote:
>
> 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.

I'd love to see Hibernate expose this via Statistics API but to do that, 
2nd level providers would need to feed this information back to 
Hibernate in a standard way, since Hibernate should work the same way 
regardless of the provider.

I can't see this happening anytime soon, hence why I suggested something 
that Infinispan could offer but I think the points raised by Manik wrt 
the potential expensiveness and the Brian's security worries don't make 
my suggestion, as it is, viable at this point in time.

>
>>
>>
>> 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
>
>
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache