[Person#1:[created:123456,lifespan:120000,maxIdle:60000,lasUsed:13456], Person#2:[created:234567,lifespan:120000,maxIdle:60000,lasUsed:24567], ...]

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,

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