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

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#... >> >> 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev