cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dariusz Łuksza <>
Subject Re: [c3 monitoring] Cache overview
Date Fri, 24 Jul 2009 19:59:08 GMT
2009/7/21 Dariusz Łuksza <>:
> On Tue, Jul 21, 2009 at 1:03 PM, Reinhard Pötz<> 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 ;)

For our needs every pipeline should have an id parameter, from one
hand it is very good solution because we get simple way how to divide
and present cache entry's on JMX and on the other hand I'm not quite
sure that we can require that parameter for every pipeline and user even if he
don't use monitoring module

What do you think ?

Best regards


View raw message