[c3 monitoring] Statistics module.

[Dariusz Łuksza]

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 ?

--
Best regards

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

[Reinhard Pötz-2]

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

Finally a list of all available properties (see the settings bean) would
be a good idea.

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

[Dariusz Łuksza]

On Fri, Jul 31, 2009 at 12:11 AM, Reinhard Pötz<reinhard@...> 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).

Good suggestions ;). Right now I'm fighting with my self what to do
... write user doc for cache overview or start implementing statistics
module ;)

> Finally a list of all available properties (see the settings bean) would
> be a good idea.
>

This IMHO should be added into "reconfiguration module" (with right
now is actually "log4j reconfiguration") not into "monitoring module".
I'll try to implement that if I find some time ;)

Any other ideas/suggestions ? ;)
--
Best regards

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

[Dariusz Łuksza]

On Fri, Jul 31, 2009 at 12:11 AM, Reinhard Pötz<reinhard@...> 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(XMLSitemapServlet.java:257)
        at org.apache.cocoon.servlet.XMLSitemapServlet.service(XMLSitemapServlet.java:98)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
        at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:77)
        at org.apache.cocoon.jnet.URLHandlerFactoryCollector.installURLHandlers(URLHandlerFactoryCollector.java:37)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:627)
        at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:616)
        at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:64)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
        at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
        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 ? :|

> Finally a list of all available properties (see the settings bean) would
> be a good idea.
>

This feature is currently implemented and I even add patch to jira COCOON3-33 ;)

--
Best regards

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

[Reinhard Pötz-2]

Dariusz Łuksza wrote:

> On Fri, Jul 31, 2009 at 12:11 AM, Reinhard Pötz<reinhard@...> 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(XMLSitemapServlet.java:257)
> at org.apache.cocoon.servlet.XMLSitemapServlet.service(XMLSitemapServlet.java:98)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
> at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:77)
> at org.apache.cocoon.jnet.URLHandlerFactoryCollector.installURLHandlers(URLHandlerFactoryCollector.java:37)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:627)
> at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:616)
> at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:64)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> 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.

HTH

>> Finally a list of all available properties (see the settings bean) would
>> be a good idea.
>>
>
> This feature is currently implemented and I even add patch to jira COCOON3-33 ;)

:-)

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

[Reinhard Pötz-2]

Reinhard Pötz wrote:

> Dariusz Łuksza wrote:
>> On Fri, Jul 31, 2009 at 12:11 AM, Reinhard Pötz<reinhard@...> 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(XMLSitemapServlet.java:257)
>> at org.apache.cocoon.servlet.XMLSitemapServlet.service(XMLSitemapServlet.java:98)
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
>> at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
>> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
>> at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:77)
>> at org.apache.cocoon.jnet.URLHandlerFactoryCollector.installURLHandlers(URLHandlerFactoryCollector.java:37)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:627)
>> at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:616)
>> at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:64)
>> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
>> at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
>> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
>> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
>> 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.

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

[Dariusz Łuksza]

On Wed, Aug 5, 2009 at 11:25 PM, Reinhard Pötz<reinhard@...> wrote:

> Reinhard Pötz wrote:
>> Dariusz Łuksza wrote:
>>> On Fri, Jul 31, 2009 at 12:11 AM, Reinhard Pötz<reinhard@...> 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(XMLSitemapServlet.java:257)
>>>      at org.apache.cocoon.servlet.XMLSitemapServlet.service(XMLSitemapServlet.java:98)
>>>      at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>      at java.lang.reflect.Method.invoke(Method.java:597)
>>>      at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
>>>      at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
>>>      at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
>>>      at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:77)
>>>      at org.apache.cocoon.jnet.URLHandlerFactoryCollector.installURLHandlers(URLHandlerFactoryCollector.java:37)
>>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>      at java.lang.reflect.Method.invoke(Method.java:597)
>>>      at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:627)
>>>      at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:616)
>>>      at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:64)
>>>      at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
>>>      at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
>>>      at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
>>>      at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
>>>      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.
>

Thanks for that tints they are very helpful right now ;).

--
Best regards

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

[Dariusz Łuksza]

On Wed, Aug 5, 2009 at 11:25 PM, Reinhard Pötz<reinhard@...> wrote:

> Reinhard Pötz wrote:
>> Dariusz Łuksza wrote:
>>> On Fri, Jul 31, 2009 at 12:11 AM, Reinhard Pötz<reinhard@...> 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(XMLSitemapServlet.java:257)
>>>      at org.apache.cocoon.servlet.XMLSitemapServlet.service(XMLSitemapServlet.java:98)
>>>      at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>      at java.lang.reflect.Method.invoke(Method.java:597)
>>>      at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
>>>      at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
>>>      at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
>>>      at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:77)
>>>      at org.apache.cocoon.jnet.URLHandlerFactoryCollector.installURLHandlers(URLHandlerFactoryCollector.java:37)
>>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>      at java.lang.reflect.Method.invoke(Method.java:597)
>>>      at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:627)
>>>      at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:616)
>>>      at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:64)
>>>      at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
>>>      at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
>>>      at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
>>>      at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
>>>      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

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

[Dariusz Łuksza]

Hi all,

For last few days I'm back on track with my project. In my latest
patch[0] I've published StatisticsCollector class and cruelty I have
some issues connected with SortedMap (methods:
getAllHitCountListAsc(), getAllHitCountListDesc(),
getHitCountListAsc(long), getHitCountListDesc(long)).

It appears that this class can't be used via JMX because of
serialization problems that occurs when I gave it costume Comparator
implementation. The Comparator interface doesn't extends Serializable
interface so I've created an extra SerializableComparator interface
that merge both interfaces. This way NotSerializableException were
fixed but next problem has occurs, this time it is connected with RMI
and Java Security policy. IMHO creating exceptions in default security
policy for this minor feature isn't good idea.

I was wondering what else can I do and right now only idea I had is
that, the only solution for this problem is to abandon this idea and
don't expose sorted statistics list on JXM with is quite ugly
solution.

Maybe somebody could gave me some a hints for another solution ?

[0] https://issues.apache.org/jira/secure/attachment/12416127/statistics-StatisticsCollector.patch
--
Best regards

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

[Reinhard Pötz-2]

Dariusz Łuksza wrote:

> Hi all,
>
> For last few days I'm back on track with my project. In my latest
> patch[0] I've published StatisticsCollector class and cruelty I have
> some issues connected with SortedMap (methods:
> getAllHitCountListAsc(), getAllHitCountListDesc(),
> getHitCountListAsc(long), getHitCountListDesc(long)).
>
> It appears that this class can't be used via JMX because of
> serialization problems that occurs when I gave it costume Comparator
> implementation. The Comparator interface doesn't extends Serializable
> interface so I've created an extra SerializableComparator interface
> that merge both interfaces. This way NotSerializableException were
> fixed but next problem has occurs, this time it is connected with RMI
> and Java Security policy. IMHO creating exceptions in default security
> policy for this minor feature isn't good idea.
>
> I was wondering what else can I do and right now only idea I had is
> that, the only solution for this problem is to abandon this idea and
> don't expose sorted statistics list on JXM with is quite ugly
> solution.
>
> Maybe somebody could gave me some a hints for another solution ?
>
> [0] https://issues.apache.org/jira/secure/attachment/12416127/statistics-StatisticsCollector.patch

Great to see you back! I will look into your patch next week.

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

[Reinhard Pötz-2]

Dariusz Łuksza wrote:

> Hi all,
>
> For last few days I'm back on track with my project. In my latest
> patch[0] I've published StatisticsCollector class and cruelty I have
> some issues connected with SortedMap (methods:
> getAllHitCountListAsc(), getAllHitCountListDesc(),
> getHitCountListAsc(long), getHitCountListDesc(long)).
>
> It appears that this class can't be used via JMX because of
> serialization problems that occurs when I gave it costume Comparator
> implementation. The Comparator interface doesn't extends Serializable
> interface so I've created an extra SerializableComparator interface
> that merge both interfaces. This way NotSerializableException were
> fixed but next problem has occurs, this time it is connected with RMI
> and Java Security policy. IMHO creating exceptions in default security
> policy for this minor feature isn't good idea.
>
> I was wondering what else can I do and right now only idea I had is
> that, the only solution for this problem is to abandon this idea and
> don't expose sorted statistics list on JXM with is quite ugly
> solution.
>
> Maybe somebody could gave me some a hints for another solution ?
>
> [0] https://issues.apache.org/jira/secure/attachment/12416127/statistics-StatisticsCollector.patch

Dariusz,

could you provide a patch that directly shows the RMI problem?

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

[Dariusz Łuksza]

On Tue, Nov 10, 2009 at 5:07 PM, Reinhard Pötz <reinhard@...> wrote:

> Dariusz Łuksza wrote:
>> Hi all,
>>
>> For last few days I'm back on track with my project. In my latest
>> patch[0] I've published StatisticsCollector class and cruelty I have
>> some issues connected with SortedMap (methods:
>> getAllHitCountListAsc(), getAllHitCountListDesc(),
>> getHitCountListAsc(long), getHitCountListDesc(long)).
>>
>> It appears that this class can't be used via JMX because of
>> serialization problems that occurs when I gave it costume Comparator
>> implementation. The Comparator interface doesn't extends Serializable
>> interface so I've created an extra SerializableComparator interface
>> that merge both interfaces. This way NotSerializableException were
>> fixed but next problem has occurs, this time it is connected with RMI
>> and Java Security policy. IMHO creating exceptions in default security
>> policy for this minor feature isn't good idea.
>>
>> I was wondering what else can I do and right now only idea I had is
>> that, the only solution for this problem is to abandon this idea and
>> don't expose sorted statistics list on JXM with is quite ugly
>> solution.
>>
>> Maybe somebody could gave me some a hints for another solution ?
>>
>> [0] https://issues.apache.org/jira/secure/attachment/12416127/statistics-StatisticsCollector.patch
>
> Dariusz,
>
> could you provide a patch that directly shows the RMI problem?
>

In attachment is that contains my last changes for this module.

In comparison to last patch I've moved sorting from
StatisticsCollector inside the Statistics class that is actually an
MBean.

Error will occur if you will try to execute getHitCountListAsc or
getHitCountListDesc.

--
Best regards

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

[Reinhard Pötz-2]

Dariusz Łuksza wrote:

> On Tue, Nov 10, 2009 at 5:07 PM, Reinhard Pötz <reinhard@...> wrote:
>> Dariusz Łuksza wrote:
>>> Hi all,
>>>
>>> For last few days I'm back on track with my project. In my latest
>>> patch[0] I've published StatisticsCollector class and cruelty I have
>>> some issues connected with SortedMap (methods:
>>> getAllHitCountListAsc(), getAllHitCountListDesc(),
>>> getHitCountListAsc(long), getHitCountListDesc(long)).
>>>
>>> It appears that this class can't be used via JMX because of
>>> serialization problems that occurs when I gave it costume Comparator
>>> implementation. The Comparator interface doesn't extends Serializable
>>> interface so I've created an extra SerializableComparator interface
>>> that merge both interfaces. This way NotSerializableException were
>>> fixed but next problem has occurs, this time it is connected with RMI
>>> and Java Security policy. IMHO creating exceptions in default security
>>> policy for this minor feature isn't good idea.
>>>
>>> I was wondering what else can I do and right now only idea I had is
>>> that, the only solution for this problem is to abandon this idea and
>>> don't expose sorted statistics list on JXM with is quite ugly
>>> solution.
>>>
>>> Maybe somebody could gave me some a hints for another solution ?
>>>
>>> [0] https://issues.apache.org/jira/secure/attachment/12416127/statistics-StatisticsCollector.patch
>> Dariusz,
>>
>> could you provide a patch that directly shows the RMI problem?
>>
>
> In attachment is that contains my last changes for this module.
>
> In comparison to last patch I've moved sorting from
> StatisticsCollector inside the Statistics class that is actually an
> MBean.
>
> Error will occur if you will try to execute getHitCountListAsc or
> getHitCountListDesc.
>

Unfortunately I can't find a solution for this serialization issue of a
TreeMap either.

Let's forget about sorting in the JMX bean unless somebody else comes up
with a solution that doesn't require the configuration of a
SecurityManager. And if we once provide a nice web UI we can sort there.

I applied your patch without the sorting feature.


Many thanks for keeping up your great work also after your very
successful GSoC project.

Do you have any further plans with the cocoon-monitoring module? (e.g.
some integration tests that check that JMX works properly or a web UI)

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

[Dariusz Łuksza]

On Sat, Nov 21, 2009 at 4:24 PM, Reinhard Pötz <reinhard@...> wrote:

> Dariusz Łuksza wrote:
>
> Unfortunately I can't find a solution for this serialization issue of a
> TreeMap either.
>
> Let's forget about sorting in the JMX bean unless somebody else comes up
> with a solution that doesn't require the configuration of a
> SecurityManager. And if we once provide a nice web UI we can sort there.
>
> I applied your patch without the sorting feature.

OK, thank you. This patch contains class
PipelineHitCountStatisticsCollector that isn't actually a valid aspect
because I forget to define a pointcut for it. I'll fix it and send a
patch.

> Many thanks for keeping up your great work also after your very
> successful GSoC project.
>
> Do you have any further plans with the cocoon-monitoring module? (e.g.
> some integration tests that check that JMX works properly or a web UI)
>

Actually I have some plans. I want to make it a fully functional and
usable cocoon3 module ;). As we talk before (in private mails), next
on my TODO are integration tests and then web UI. Right now I want to
finish statistics part of module (IMHO there could be more aspect's
for getting more stats from cocoon). Also I'm thinking about some
improvements in monitoring configuration, right now there are specific
beans definitions for each part of monitoring, maybe that could be
done better (e.g. (re)move constructor/property dependency injection
so we can get simpler bean definition).

--
Best regards

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