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

Manik Surtani manik at jboss.org
Thu Nov 26 06:44:48 EST 2009

On 26 Nov 2009, at 09:16, 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.
> [Person#1:[created:123456,lifespan:120000,maxIdle:60000,lasUsed:13456],
> Person#2:[created:234567,lifespan:120000,maxIdle:60000,lasUsed:24567],
> ...]
> We could event add calculated properties such as 'age' which is current 
> - created. This would vary with each call obviously.

Surely that would be hugely expensive?  To iterate through the entire collection?  And what when you have JOPR polling this value every 5 seconds or something? ;)

> 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,
> -- 
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
> _______________________________________________
> 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

More information about the hibernate-dev mailing list