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