On Tue, Jul 21, 2009 at 1:03 PM, Reinhard Pötz<[email protected]> wrote: > Simone Gianni wrote: >> Hi Dariusz, >> I had a look at your patch. I see the method "listKeys", with the >> description "Removes all cached data". I think this is an error, looking >> at the source it lists cache key names, and does not remove them, while >> the "clear" method does that. >> >> Apart from this small error, regarding your question, I'm trying to >> figure out what a user will want to see when checking the cache. >> >> I'm brainstorming here, trying to paint a big picture, probably the real >> features will be much smaller, but this could provide you ideas and at >> the same time help identify which ones are most important. >> >> I can think of three possible scenarios : >> - While developing, they see something they don't expect to see, and >> they go check if there is some cached data in the way. >> - While optimizing the application, they go check what happens in the >> cache, if/how they are wasting RAM by caching too much or wasting CPU by >> not caching enough. >> - At runtime, they could access it to see what's going wrong, to recover >> some ram, to clear everything if they just published something really >> important and they want it to appear now. >> >> 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. > > In Cocoon 2.x, a pipeline can have and ID attribute. For the purpose of > drilling down caching entries we could introduce it in 3.0 too. (I've > always wondered about the use case for pipeline ids ...) >
Thanks for that tip I'll look on this ASAP ;) -- Best regards Blog: http://luksza.org LinkedIn: http://www.linkedin.com/in/dariuszluksza
