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 20:29:39 GMT
2009/7/24 Dariusz Łuksza <>:
> 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 ?

There is also third solution ... pipeline id parameter can be optional
and we'll publish on JMX _only_ that cache entry's that belongs to
pipeline that have set id parameter. This approach gives us additional
configuration options and can reduce amount of data published on JMX.
IMHO this is the best solution right now.

Best regards


View raw message