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 Wed, 05 Aug 2009 21:12:17 GMT
Dariusz Łuksza wrote:
> On Mon, Jul 27, 2009 at 4:18 PM, Reinhard Pötz<reinhard@apache.org> wrote:
>> Dariusz Łuksza wrote:
>>> 2009/7/24 Dariusz Łuksza <dariusz.luksza@gmail.com>:
>>>>> 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
>>
> 
> And here it is:
> https://issues.apache.org/jira/secure/attachment/12414657/cache-overview-part3-cache-entrys.patch
> 
> What operation (besides: getValue() and getSize()), would be useful
> for every cache entry ?

Everything works great, thanks!

There is one thing that I would like to see changed: You set the
jmx-group-name in the cache key. I would prefer if this would do the
pipeline itself instead because imo jmx is not the cache key's concern.
The second reason is that your implementation only works by accident
because you can access the <pipeline> parameters (in this case
'jmx-group-name') in components which is a bug IMO.

Instead you can override the setConfiguration() Method in the
CachingPipeline in order to get access to its parameters and use the
value in setCachedValue().

                                  - o -

I know that it's not part of your GSoC project, but if time permits now
or after it, it would be great to get some basic integration tests that
check if the JMX beans are exposed. This will make ensure that the
functionality doesn't get broken fundamentally.

-- 
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