On Fri, Jul 17, 2009 at 7:16 AM, Reinhard Pötz<[email protected]> wrote: > Dariusz Łuksza wrote: >> On Wed, Jul 15, 2009 at 8:43 PM, Simone Gianni<[email protected]> wrote: >>> >>> Given these three scenarios, these are things that may be useful to see via >>> JMX, but I don't know which of them are actually achievable or already >>> there, so this is an "abstract" POV : >>> - The component that stored that entry (it's part of the name already for >>> ComponentCacheKey) >>> - Which "pipeline" I'm referring to, so that if it's not working properly I >>> can check if there is cached stuff. >>> - The size of the entry, I see it is possible to obtain it from CacheKey >>> with your patch. this is useful if I'm profiling or in desperate need to >>> free some ram. >>> - When that entry will expire by itself, if it will. >>> - Last time that entry has been used (red) from the cache, if ever. >> >> Here you generally refer to single cache entry. But question how to >> represent cache entry on JMX tree is still actual. I have two ideas >> how we can do that: >> - based on URL with they published >> - based on pipeline and type of cache > > Just one quick comment for now (I'll get back to you with more thoughts > at the weekend but the discussions already goes into the right direction > IMHO): > Does this still work if you have thousands or tens of thousands cache > entries? >
In this case it'll cost some CPU time and user patience to find elemnt that he is actually looking for, but right now I don't have anny other ideas ... -- Best regards Blog: http://luksza.org LinkedIn: http://www.linkedin.com/in/dariuszluksza
