cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dariusz Łuksza <dariusz.luk...@gmail.com>
Subject Re: [c3 monitoring] Cache overview
Date Thu, 06 Aug 2009 06:35:42 GMT
On Wed, Aug 5, 2009 at 11:12 PM, Reinhard Pötz<reinhard@apache.org> wrote:
> 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().

OK, I'll change it ASAP.

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

I think that I'll continue working on this project after GSoC so
integration tests (and other improvements) would be implemented in
near future ;)

-- 
Best regards

Blog: http://luksza.org
LinkedIn: http://www.linkedin.com/in/dariuszluksza

Mime
View raw message