cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dariusz Łuksza <>
Subject Re: [c3 monitoring] Statistics module.
Date Thu, 06 Aug 2009 20:36:21 GMT
On Wed, Aug 5, 2009 at 11:25 PM, Reinhard Pötz<> wrote:
> Reinhard Pötz wrote:
>> Dariusz Łuksza wrote:
>>> On Fri, Jul 31, 2009 at 12:11 AM, Reinhard Pötz<> wrote:
>>>> Dariusz Łuksza wrote:
>>>>> Hi all,
>>>>> Currently I'm finishing milestone 3 (actually it is "cache overview")
>>>>> of my GSoC project and I've started to wondering about last part of
>>>>> this project: statistics module.
>>>>> I want that this module would be as much useful as it could be, so the
>>>>> main question is what statistics should be exposed in this module ?
>>>>> One proposition is monitoring of cache. Showing what cache entry's are:
>>>>> * most often read
>>>>> * most often generated
>>>>> I think that having some informations about pipeline usage would be
>>>>> also useful. Right now I think that exposing hit count for every named
>>>>> (it means that it has set "jmx-group-name" parameter) pipeline. This
>>>>> would be useful for proper cache configuration.
>>>>> Any other propositions ?
>>>> I think it is a good idea to get an overview of all cache entries that
>>>> are never used at all.
>>>> Also a general request counter would be useful (number of request in the
>>>> last 5 minutes, 60 minutes, 24 hours, since system start).
>>> In attachment is a patch that adds that functionality but
>>> unfortunately it doesn't work because of ClassCastException. Here is
>>> part of stack trace:
>>> java.lang.ClassCastException:
>>> org.apache.cocoon.monitoring.statistics.RequestCounter cannot be cast
>>> to org.apache.cocoon.monitoring.statistics.RequestCounter
>>>      at org.apache.cocoon.servlet.XMLSitemapServlet.lazyInitialize(
>>>      at org.apache.cocoon.servlet.XMLSitemapServlet.service(
>>>      at javax.servlet.http.HttpServlet.service(
>>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>      at sun.reflect.NativeMethodAccessorImpl.invoke(
>>>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>>>      at java.lang.reflect.Method.invoke(
>>>      at
>>>      at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(
>>>      at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(
>>>      at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(
>>>      at org.apache.cocoon.jnet.URLHandlerFactoryCollector.installURLHandlers(
>>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>      at sun.reflect.NativeMethodAccessorImpl.invoke(
>>>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>>>      at java.lang.reflect.Method.invoke(
>>>      at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(
>>>      at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(
>>>      at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(
>>>      at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(
>>>      at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(
>>>      at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(
>>>      at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(
>>>      at $Proxy21.service(Unknown Source)
>>> I cannot obtain bean
>>> "org.apache.cocoon.monitoring.statistics.RequestCounter" from
>>> BeanFactory. For me this a very strange thing because exception is
>>> saying: "Cannot cast class A to class A" WTF ? :|
>> This means that you experience some classloading issues: The class
>> loader that loaded the source object (class) is different from the class
>> loader that loaded the target class.
> You added cocoon-monitoring as a dependency to cocoon-servlet. We
> shouldn't do this for two reason: First, I consider the
> cocoon-monitoring as an add-on and we shouldn't force its usage. Second,
> see the stacktrace above ;-)
> I propose that you move the request counter bean to cocoon-servlet and
> access it then from some JMX bean.
> The other thing I'm not completely happy about is that you have to add
> the code that increments the request counter into every servlet. I
> propose to rely on AOP to get this problem solved. COCOON3-40 should
> provide some hints how to get this done.

AFAIU AOP ideas, I can leave counter bean in monitoring module and
with AspectJ I can plug in every place that I want to. IMHO that
solution would be cleaner and better ;)

Best regards


View raw message