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 21:07:18 GMT
On Thu, Aug 6, 2009 at 11:01 PM, Reinhard Pötz<reinhard@apache.org> wrote:
> Dariusz Łuksza wrote:
>> 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().
>>>
>>
>> In latest patch I've added obtaining "jmx-group-name" parameter to
>> setConfiguration() in CachingPipeline, so IMHO first part of yours
>> suggestion is implemented right now. I can't understood second part of
>> yours suggestion (that connected with setCacheValue()). As far as I
>> understood it right now, I should set "jmx-group-name" for every
>> CacheKey that is passed to setCacheValue() and then get that name in
>> CacheEntrysMonitorInitializer.processCaches(). But if I done that I'll
>> not separate CacheKey form pipeline parametes, as you suggested above
>> ...
>>
>> Could you describe more it more precisely ?
>
>
> I was referring to
>
> +++
> cocoon-stringtemplate/src/main/java/org/apache/cocoon/stringtemplate/StringTemplateReader.java
> (working copy)
> @@ -73,7 +73,7 @@
>
>         try {
>             cacheKey.addCacheKey(new TimestampCacheKey(this.source,
> this.source.openConnection().getLastModified()));
> -            cacheKey.addCacheKey(new ParameterCacheKey(this.parameters));
> +            cacheKey.addCacheKey(new ParameterCacheKey(this.parameters,
> (String) parameters.get("jmx-group-name")));
>         } catch (IOException e) {
>             throw new SetupException("Could not create cache key.", e);
>         }
>
>
>
> You add the jmx-group-name in *every* compnent that creates a cache key.
> I prefer to do this transparently for every cache key in the
> setCacheValue() method of the CachingPipeline. Hope it's clearer now.
>

Yes, right now it is clear enough.

-- 
Best regards

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

Mime
View raw message