cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <reinh...@apache.org>
Subject Re: [c3 monitoring] Cache overview
Date Mon, 27 Jul 2009 14:18:33 GMT
Dariusz Łuksza wrote:
> 2009/7/24 Dariusz Łuksza <dariusz.luksza@gmail.com>:
>> 2009/7/21 Dariusz Łuksza <dariusz.luksza@gmail.com>:
>>> On Tue, Jul 21, 2009 at 1:03 PM, Reinhard Pötz<reinhard@apache.org> 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.

+1

-- 
Reinhard Pötz                           Managing Director, {Indoqa} GmbH
                         http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@apache.org
________________________________________________________________________

Mime
View raw message