From asoldano at redhat.com  Tue Jul  1 04:37:43 2014
From: asoldano at redhat.com (Alessio Soldano)
Date: Tue, 01 Jul 2014 10:37:43 +0200
Subject: [jbossws-dev] Fwd: EndpointMetrics Refactor
In-Reply-To: <53B26A36.4080102@redhat.com>
References: <53B26A36.4080102@redhat.com>
Message-ID: <53B27357.10102@redhat.com>

Moving discussion to public dev list


-------- Original Message --------
Subject: 	EndpointMetrics Refactor
Date: 	Tue, 01 Jul 2014 15:58:46 +0800
From: 	Jim Ma <ema at redhat.com>
To: 	Alessio Soldano <asoldano at redhat.com>, Rebecca Searls 
<rsearls at redhat.com>



Hi Alessio & Rebecca,

After discussed on IRC last week, looked at cxf's management code in
more depth
and wrote something to verify yesterday, it's time to sum up what can we
do to refactor
the current EndpointMetrics as I promised to make it better work with
cxf's management
implementation.

At the beginning,  I'd like to quickly list the cons of the current
EndpointMetrics
implementation.
- Because the statistics is fulfilled in RequestHandlerImpl , after the
response is successfully
     returned to receiver. The response related metric value could not
be updated in time, more
     details pleas see JBWS-3808
- It doesn't count the one way fault correctly.
- It doesn't expose all the attribute in jmx.
- If the cxf's management is enabled, user will get two different
statistics value. One is
     calculated  with jbossws-cxf's endpointmetrics which happens in
RequestHandler(servlet),
     and another one is calculated with ResponseTimeInterceptor(cxf's
interceptor).
The pros of current implementation :
  - It gives more accurate start time for each request.
  - It is simple and doesn't need to add more interceptor/extra code in
the runtime to collect
      the data.

 From the above analysis, one important thing we need to do is make the
EndpintMetrics seamlessly
work with cxf's management intercetptor and get statistics from one
place instead of generate two
copies from different implementation.
There is CounterRepostiry extension in cxf  which responsible for
creating ResponseTimeCounter
for each endpoint,  It can be the only source we get statistics for each
endpoint.
To get metric value from this class, we need to change following things:
1. Each ResponseTImeCounter(something similar to EndpointMetrics) is
lazily created in
     message interceptor and put in CounterReposiory with a long
ObjectName at the moment. We
     need to change it and add the ResponseTimeCounter for each jbossws
endpoint , then put it in
     CounterRepostiry with key name of endpoint name.
2. Change EndpointMetricsFactory abstract class to create with
EndpointMetric with endpoint
     parameter so the endpoint name can be used to create
ResponseTimeCounter.
3. Create new EndpointMetricImpl in jbossws-cxf and get metric value
from ResponseCounter
    which is created for each endpoint.
4. Change the ResponseTimeInterceptor and allow for define the counter
object name.

Besides this , I also need to refactor the ResponseTimeInterceptor to
make it log the process time
more accurate(by move ResponseTimeInInterceptor before several
interceptors ?). And also refactor
the ResponseTimeInterceptor a bit to handle the fault message correctly.

If you have any question and comments about this change , please let me
know.

Thanks,
Jim



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbossws-dev/attachments/20140701/e06dc1b3/attachment.html 

From asoldano at redhat.com  Wed Jul  2 10:52:28 2014
From: asoldano at redhat.com (Alessio Soldano)
Date: Wed, 02 Jul 2014 16:52:28 +0200
Subject: [jbossws-dev] Fwd: EndpointMetrics Refactor
In-Reply-To: <53B27357.10102@redhat.com>
References: <53B26A36.4080102@redhat.com> <53B27357.10102@redhat.com>
Message-ID: <53B41CAC.4080703@redhat.com>

Hi Jim,

>
> At the beginning,  I'd like to quickly list the cons of the current
> EndpointMetrics
> implementation.
> - Because the statistics is fulfilled in RequestHandlerImpl , after the
> response is successfully
>      returned to receiver. The response related metric value could not
> be updated in time, more
>      details pleas see JBWS-3808
> - It doesn't count the one way fault correctly.
yep, we need more consistent values to be returned by metric queries.

> - It doesn't expose all the attribute in jmx.
This is not necessarily a requirement, but a nice to have.

> - If the cxf's management is enabled, user will get two different
> statistics value. One is
>      calculated  with jbossws-cxf's endpointmetrics which happens in
> RequestHandler(servlet),
>      and another one is calculated with ResponseTimeInterceptor(cxf's
> interceptor).
right, and this is possibly confusing users, while we could rely on the 
existing cxf mechanism...


> The pros of current implementation :
>   - It gives more accurate start time for each request.
>   - It is simple and doesn't need to add more interceptor/extra code in
> the runtime to collect
>       the data.

In any case, regardless of which solution we eventually end up relying 
on, we need to make the data collection as light as possible and, more 
important, we need to make sure you can disable statistics and get no 
performance degradation at all.

> >From the above analysis, one important thing we need to do is make the
> EndpintMetrics seamlessly
> work with cxf's management intercetptor and get statistics from one
> place instead of generate two
> copies from different implementation.
+1

> There is CounterRepostiry extension in cxf  which responsible for
> creating ResponseTimeCounter
> for each endpoint,  It can be the only source we get statistics for each
> endpoint.
> To get metric value from this class, we need to change following things:
> 1. Each ResponseTImeCounter(something similar to EndpointMetrics) is
> lazily created in
>      message interceptor and put in CounterReposiory with a long
> ObjectName at the moment. We
>      need to change it and add the ResponseTimeCounter for each jbossws
> endpoint , then put it in
>      CounterRepostiry with key name of endpoint name.
> 2. Change EndpointMetricsFactory abstract class to create with
> EndpointMetric with endpoint
>      parameter so the endpoint name can be used to create
> ResponseTimeCounter.
> 3. Create new EndpointMetricImpl in jbossws-cxf and get metric value
> from ResponseCounter
>     which is created for each endpoint.
> 4. Change the ResponseTimeInterceptor and allow for define the counter
> object name.
>
> Besides this , I also need to refactor the ResponseTimeInterceptor to
> make it log the process time
> more accurate(by move ResponseTimeInInterceptor before several
> interceptors ?). And also refactor
> the ResponseTimeInterceptor a bit to handle the fault message correctly.
The plan might work afaics here. The details are probably the core of 
the issue ;-) I think you can provide a prototype and we can have a look 
together. Just always keep in mind my comment above regarding 
performance and being able to disable the stats at runtime to have full 
perf.

Cheers
Alessio

-- 
Alessio Soldano
Web Service Lead, JBoss


From ema at redhat.com  Wed Jul  2 23:35:42 2014
From: ema at redhat.com (Jim Ma)
Date: Thu, 03 Jul 2014 11:35:42 +0800
Subject: [jbossws-dev] Fwd: EndpointMetrics Refactor
In-Reply-To: <53B41CAC.4080703@redhat.com>
References: <53B26A36.4080102@redhat.com> <53B27357.10102@redhat.com>
	<53B41CAC.4080703@redhat.com>
Message-ID: <53B4CF8E.7060008@redhat.com>

Thanks for all your input, Alessio. I've already created prototype code,
will create some workspace and check in later.

On 07/02/2014 10:52 PM, Alessio Soldano wrote:
> Hi Jim,
>
>> At the beginning,  I'd like to quickly list the cons of the current
>> EndpointMetrics
>> implementation.
>> - Because the statistics is fulfilled in RequestHandlerImpl , after the
>> response is successfully
>>       returned to receiver. The response related metric value could not
>> be updated in time, more
>>       details pleas see JBWS-3808
>> - It doesn't count the one way fault correctly.
> yep, we need more consistent values to be returned by metric queries.
>
>> - It doesn't expose all the attribute in jmx.
> This is not necessarily a requirement, but a nice to have.
>
>> - If the cxf's management is enabled, user will get two different
>> statistics value. One is
>>       calculated  with jbossws-cxf's endpointmetrics which happens in
>> RequestHandler(servlet),
>>       and another one is calculated with ResponseTimeInterceptor(cxf's
>> interceptor).
> right, and this is possibly confusing users, while we could rely on the
> existing cxf mechanism...
>
>
>> The pros of current implementation :
>>    - It gives more accurate start time for each request.
>>    - It is simple and doesn't need to add more interceptor/extra code in
>> the runtime to collect
>>        the data.
> In any case, regardless of which solution we eventually end up relying
> on, we need to make the data collection as light as possible and, more
> important, we need to make sure you can disable statistics and get no
> performance degradation at all.
>
>> >From the above analysis, one important thing we need to do is make the
>> EndpintMetrics seamlessly
>> work with cxf's management intercetptor and get statistics from one
>> place instead of generate two
>> copies from different implementation.
> +1
>
>> There is CounterRepostiry extension in cxf  which responsible for
>> creating ResponseTimeCounter
>> for each endpoint,  It can be the only source we get statistics for each
>> endpoint.
>> To get metric value from this class, we need to change following things:
>> 1. Each ResponseTImeCounter(something similar to EndpointMetrics) is
>> lazily created in
>>       message interceptor and put in CounterReposiory with a long
>> ObjectName at the moment. We
>>       need to change it and add the ResponseTimeCounter for each jbossws
>> endpoint , then put it in
>>       CounterRepostiry with key name of endpoint name.
>> 2. Change EndpointMetricsFactory abstract class to create with
>> EndpointMetric with endpoint
>>       parameter so the endpoint name can be used to create
>> ResponseTimeCounter.
>> 3. Create new EndpointMetricImpl in jbossws-cxf and get metric value
>> from ResponseCounter
>>      which is created for each endpoint.
>> 4. Change the ResponseTimeInterceptor and allow for define the counter
>> object name.
>>
>> Besides this , I also need to refactor the ResponseTimeInterceptor to
>> make it log the process time
>> more accurate(by move ResponseTimeInInterceptor before several
>> interceptors ?). And also refactor
>> the ResponseTimeInterceptor a bit to handle the fault message correctly.
> The plan might work afaics here. The details are probably the core of
> the issue ;-) I think you can provide a prototype and we can have a look
> together. Just always keep in mind my comment above regarding
> performance and being able to disable the stats at runtime to have full
> perf.
>
> Cheers
> Alessio
>


From ema at redhat.com  Mon Jul  7 04:31:54 2014
From: ema at redhat.com (Jim Ma)
Date: Mon, 07 Jul 2014 16:31:54 +0800
Subject: [jbossws-dev] Fwd: EndpointMetrics Refactor
In-Reply-To: <53B4CF8E.7060008@redhat.com>
References: <53B26A36.4080102@redhat.com>
	<53B27357.10102@redhat.com>	<53B41CAC.4080703@redhat.com>
	<53B4CF8E.7060008@redhat.com>
Message-ID: <53BA5AFA.5090102@redhat.com>

I've checked in all things related this change for your review :

https://svn.jboss.org/repos/jbossws/spi/branches/metrics
https://svn.jboss.org/repos/jbossws/common/branches/metrics
https://svn.jboss.org/repos/jbossws/stack/cxf/branches/metrics
https://github.com/jimma/wildfly/tree/metric
All the cxf change are merged : in 
https://git-wip-us.apache.org/repos/asf/cxf.git

If you have any concerns and comments, please let me know.

Thanks,
Jim

On 03/07/14 11:35, Jim Ma wrote:
> Thanks for all your input, Alessio. I've already created prototype code,
> will create some workspace and check in later.
>
> On 07/02/2014 10:52 PM, Alessio Soldano wrote:
>> Hi Jim,
>>
>>> At the beginning,  I'd like to quickly list the cons of the current
>>> EndpointMetrics
>>> implementation.
>>> - Because the statistics is fulfilled in RequestHandlerImpl , after the
>>> response is successfully
>>>        returned to receiver. The response related metric value could not
>>> be updated in time, more
>>>        details pleas see JBWS-3808
>>> - It doesn't count the one way fault correctly.
>> yep, we need more consistent values to be returned by metric queries.
>>
>>> - It doesn't expose all the attribute in jmx.
>> This is not necessarily a requirement, but a nice to have.
>>
>>> - If the cxf's management is enabled, user will get two different
>>> statistics value. One is
>>>        calculated  with jbossws-cxf's endpointmetrics which happens in
>>> RequestHandler(servlet),
>>>        and another one is calculated with ResponseTimeInterceptor(cxf's
>>> interceptor).
>> right, and this is possibly confusing users, while we could rely on the
>> existing cxf mechanism...
>>
>>
>>> The pros of current implementation :
>>>     - It gives more accurate start time for each request.
>>>     - It is simple and doesn't need to add more interceptor/extra code in
>>> the runtime to collect
>>>         the data.
>> In any case, regardless of which solution we eventually end up relying
>> on, we need to make the data collection as light as possible and, more
>> important, we need to make sure you can disable statistics and get no
>> performance degradation at all.
>>
>>> >From the above analysis, one important thing we need to do is make the
>>> EndpintMetrics seamlessly
>>> work with cxf's management intercetptor and get statistics from one
>>> place instead of generate two
>>> copies from different implementation.
>> +1
>>
>>> There is CounterRepostiry extension in cxf  which responsible for
>>> creating ResponseTimeCounter
>>> for each endpoint,  It can be the only source we get statistics for each
>>> endpoint.
>>> To get metric value from this class, we need to change following things:
>>> 1. Each ResponseTImeCounter(something similar to EndpointMetrics) is
>>> lazily created in
>>>        message interceptor and put in CounterReposiory with a long
>>> ObjectName at the moment. We
>>>        need to change it and add the ResponseTimeCounter for each jbossws
>>> endpoint , then put it in
>>>        CounterRepostiry with key name of endpoint name.
>>> 2. Change EndpointMetricsFactory abstract class to create with
>>> EndpointMetric with endpoint
>>>        parameter so the endpoint name can be used to create
>>> ResponseTimeCounter.
>>> 3. Create new EndpointMetricImpl in jbossws-cxf and get metric value
>>> from ResponseCounter
>>>       which is created for each endpoint.
>>> 4. Change the ResponseTimeInterceptor and allow for define the counter
>>> object name.
>>>
>>> Besides this , I also need to refactor the ResponseTimeInterceptor to
>>> make it log the process time
>>> more accurate(by move ResponseTimeInInterceptor before several
>>> interceptors ?). And also refactor
>>> the ResponseTimeInterceptor a bit to handle the fault message correctly.
>> The plan might work afaics here. The details are probably the core of
>> the issue ;-) I think you can provide a prototype and we can have a look
>> together. Just always keep in mind my comment above regarding
>> performance and being able to disable the stats at runtime to have full
>> perf.
>>
>> Cheers
>> Alessio
>>
> _______________________________________________
> jbossws-dev mailing list
> jbossws-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbossws-dev


From asoldano at redhat.com  Mon Jul  7 05:03:44 2014
From: asoldano at redhat.com (Alessio Soldano)
Date: Mon, 07 Jul 2014 11:03:44 +0200
Subject: [jbossws-dev] Fwd: EndpointMetrics Refactor
In-Reply-To: <53BA5AFA.5090102@redhat.com>
References: <53B26A36.4080102@redhat.com>
	<53B27357.10102@redhat.com>	<53B41CAC.4080703@redhat.com>
	<53B4CF8E.7060008@redhat.com> <53BA5AFA.5090102@redhat.com>
Message-ID: <53BA6270.2030708@redhat.com>

Thanks,
will have a look. Can you clarify which of the jiras on this topic 
recently created at https://issues.apache.org are actually required?
Thanks
Alessio

On 07/07/14 10:31, Jim Ma wrote:
> I've checked in all things related this change for your review :
>
> https://svn.jboss.org/repos/jbossws/spi/branches/metrics
> https://svn.jboss.org/repos/jbossws/common/branches/metrics
> https://svn.jboss.org/repos/jbossws/stack/cxf/branches/metrics
> https://github.com/jimma/wildfly/tree/metric
> All the cxf change are merged : in 
> https://git-wip-us.apache.org/repos/asf/cxf.git
>
> If you have any concerns and comments, please let me know.
>
> Thanks,
> Jim
>
> On 03/07/14 11:35, Jim Ma wrote:
>> Thanks for all your input, Alessio. I've already created prototype code,
>> will create some workspace and check in later.
>>
>> On 07/02/2014 10:52 PM, Alessio Soldano wrote:
>>> Hi Jim,
>>>
>>>> At the beginning,  I'd like to quickly list the cons of the current
>>>> EndpointMetrics
>>>> implementation.
>>>> - Because the statistics is fulfilled in RequestHandlerImpl , after 
>>>> the
>>>> response is successfully
>>>>        returned to receiver. The response related metric value 
>>>> could not
>>>> be updated in time, more
>>>>        details pleas see JBWS-3808
>>>> - It doesn't count the one way fault correctly.
>>> yep, we need more consistent values to be returned by metric queries.
>>>
>>>> - It doesn't expose all the attribute in jmx.
>>> This is not necessarily a requirement, but a nice to have.
>>>
>>>> - If the cxf's management is enabled, user will get two different
>>>> statistics value. One is
>>>>        calculated  with jbossws-cxf's endpointmetrics which happens in
>>>> RequestHandler(servlet),
>>>>        and another one is calculated with 
>>>> ResponseTimeInterceptor(cxf's
>>>> interceptor).
>>> right, and this is possibly confusing users, while we could rely on the
>>> existing cxf mechanism...
>>>
>>>
>>>> The pros of current implementation :
>>>>     - It gives more accurate start time for each request.
>>>>     - It is simple and doesn't need to add more interceptor/extra 
>>>> code in
>>>> the runtime to collect
>>>>         the data.
>>> In any case, regardless of which solution we eventually end up relying
>>> on, we need to make the data collection as light as possible and, more
>>> important, we need to make sure you can disable statistics and get no
>>> performance degradation at all.
>>>
>>>> >From the above analysis, one important thing we need to do is make 
>>>> the
>>>> EndpintMetrics seamlessly
>>>> work with cxf's management intercetptor and get statistics from one
>>>> place instead of generate two
>>>> copies from different implementation.
>>> +1
>>>
>>>> There is CounterRepostiry extension in cxf  which responsible for
>>>> creating ResponseTimeCounter
>>>> for each endpoint,  It can be the only source we get statistics for 
>>>> each
>>>> endpoint.
>>>> To get metric value from this class, we need to change following 
>>>> things:
>>>> 1. Each ResponseTImeCounter(something similar to EndpointMetrics) is
>>>> lazily created in
>>>>        message interceptor and put in CounterReposiory with a long
>>>> ObjectName at the moment. We
>>>>        need to change it and add the ResponseTimeCounter for each 
>>>> jbossws
>>>> endpoint , then put it in
>>>>        CounterRepostiry with key name of endpoint name.
>>>> 2. Change EndpointMetricsFactory abstract class to create with
>>>> EndpointMetric with endpoint
>>>>        parameter so the endpoint name can be used to create
>>>> ResponseTimeCounter.
>>>> 3. Create new EndpointMetricImpl in jbossws-cxf and get metric value
>>>> from ResponseCounter
>>>>       which is created for each endpoint.
>>>> 4. Change the ResponseTimeInterceptor and allow for define the counter
>>>> object name.
>>>>
>>>> Besides this , I also need to refactor the ResponseTimeInterceptor to
>>>> make it log the process time
>>>> more accurate(by move ResponseTimeInInterceptor before several
>>>> interceptors ?). And also refactor
>>>> the ResponseTimeInterceptor a bit to handle the fault message 
>>>> correctly.
>>> The plan might work afaics here. The details are probably the core of
>>> the issue ;-) I think you can provide a prototype and we can have a 
>>> look
>>> together. Just always keep in mind my comment above regarding
>>> performance and being able to disable the stats at runtime to have full
>>> perf.
>>>
>>> Cheers
>>> Alessio
>>>
>> _______________________________________________
>> jbossws-dev mailing list
>> jbossws-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbossws-dev
>


-- 
Alessio Soldano
Web Service Lead, JBoss


From ema at redhat.com  Mon Jul  7 05:13:56 2014
From: ema at redhat.com (Jim Ma)
Date: Mon, 07 Jul 2014 17:13:56 +0800
Subject: [jbossws-dev] Fwd: EndpointMetrics Refactor
In-Reply-To: <53BA6270.2030708@redhat.com>
References: <53B26A36.4080102@redhat.com>
	<53B27357.10102@redhat.com>	<53B41CAC.4080703@redhat.com>
	<53B4CF8E.7060008@redhat.com> <53BA5AFA.5090102@redhat.com>
	<53BA6270.2030708@redhat.com>
Message-ID: <53BA64D4.4060406@redhat.com>

These 4 cxf jiras are related to this change:
   [CXF-5847]:Add operation to enable/disable ResponseTimeCounter
   [CXF-5843]:Allow define the ObjectName of ResponseTimeCounterMBean
   [CXF-5840]:ResponseTimeCounter counts the one-way fault message twice
   [CXF-5839]:ResponseTimeCounter doesn't count the schema validation fault

With the change for this 4 JIRAs, I also did some refactor to log more 
accurate
begin/end processing time and clean up work to  remove some unused code.

Cheers,
Jim

On 07/07/14 17:03, Alessio Soldano wrote:
> Thanks,
> will have a look. Can you clarify which of the jiras on this topic 
> recently created at https://issues.apache.org are actually required?
> Thanks
> Alessio
>
> On 07/07/14 10:31, Jim Ma wrote:
>> I've checked in all things related this change for your review :
>>
>> https://svn.jboss.org/repos/jbossws/spi/branches/metrics
>> https://svn.jboss.org/repos/jbossws/common/branches/metrics
>> https://svn.jboss.org/repos/jbossws/stack/cxf/branches/metrics
>> https://github.com/jimma/wildfly/tree/metric
>> All the cxf change are merged : in 
>> https://git-wip-us.apache.org/repos/asf/cxf.git
>>
>> If you have any concerns and comments, please let me know.
>>
>> Thanks,
>> Jim
>>
>> On 03/07/14 11:35, Jim Ma wrote:
>>> Thanks for all your input, Alessio. I've already created prototype 
>>> code,
>>> will create some workspace and check in later.
>>>
>>> On 07/02/2014 10:52 PM, Alessio Soldano wrote:
>>>> Hi Jim,
>>>>
>>>>> At the beginning,  I'd like to quickly list the cons of the current
>>>>> EndpointMetrics
>>>>> implementation.
>>>>> - Because the statistics is fulfilled in RequestHandlerImpl , 
>>>>> after the
>>>>> response is successfully
>>>>>        returned to receiver. The response related metric value 
>>>>> could not
>>>>> be updated in time, more
>>>>>        details pleas see JBWS-3808
>>>>> - It doesn't count the one way fault correctly.
>>>> yep, we need more consistent values to be returned by metric queries.
>>>>
>>>>> - It doesn't expose all the attribute in jmx.
>>>> This is not necessarily a requirement, but a nice to have.
>>>>
>>>>> - If the cxf's management is enabled, user will get two different
>>>>> statistics value. One is
>>>>>        calculated  with jbossws-cxf's endpointmetrics which 
>>>>> happens in
>>>>> RequestHandler(servlet),
>>>>>        and another one is calculated with 
>>>>> ResponseTimeInterceptor(cxf's
>>>>> interceptor).
>>>> right, and this is possibly confusing users, while we could rely on 
>>>> the
>>>> existing cxf mechanism...
>>>>
>>>>
>>>>> The pros of current implementation :
>>>>>     - It gives more accurate start time for each request.
>>>>>     - It is simple and doesn't need to add more interceptor/extra 
>>>>> code in
>>>>> the runtime to collect
>>>>>         the data.
>>>> In any case, regardless of which solution we eventually end up relying
>>>> on, we need to make the data collection as light as possible and, more
>>>> important, we need to make sure you can disable statistics and get no
>>>> performance degradation at all.
>>>>
>>>>> >From the above analysis, one important thing we need to do is 
>>>>> make the
>>>>> EndpintMetrics seamlessly
>>>>> work with cxf's management intercetptor and get statistics from one
>>>>> place instead of generate two
>>>>> copies from different implementation.
>>>> +1
>>>>
>>>>> There is CounterRepostiry extension in cxf  which responsible for
>>>>> creating ResponseTimeCounter
>>>>> for each endpoint,  It can be the only source we get statistics 
>>>>> for each
>>>>> endpoint.
>>>>> To get metric value from this class, we need to change following 
>>>>> things:
>>>>> 1. Each ResponseTImeCounter(something similar to EndpointMetrics) is
>>>>> lazily created in
>>>>>        message interceptor and put in CounterReposiory with a long
>>>>> ObjectName at the moment. We
>>>>>        need to change it and add the ResponseTimeCounter for each 
>>>>> jbossws
>>>>> endpoint , then put it in
>>>>>        CounterRepostiry with key name of endpoint name.
>>>>> 2. Change EndpointMetricsFactory abstract class to create with
>>>>> EndpointMetric with endpoint
>>>>>        parameter so the endpoint name can be used to create
>>>>> ResponseTimeCounter.
>>>>> 3. Create new EndpointMetricImpl in jbossws-cxf and get metric value
>>>>> from ResponseCounter
>>>>>       which is created for each endpoint.
>>>>> 4. Change the ResponseTimeInterceptor and allow for define the 
>>>>> counter
>>>>> object name.
>>>>>
>>>>> Besides this , I also need to refactor the ResponseTimeInterceptor to
>>>>> make it log the process time
>>>>> more accurate(by move ResponseTimeInInterceptor before several
>>>>> interceptors ?). And also refactor
>>>>> the ResponseTimeInterceptor a bit to handle the fault message 
>>>>> correctly.
>>>> The plan might work afaics here. The details are probably the core of
>>>> the issue ;-) I think you can provide a prototype and we can have a 
>>>> look
>>>> together. Just always keep in mind my comment above regarding
>>>> performance and being able to disable the stats at runtime to have 
>>>> full
>>>> perf.
>>>>
>>>> Cheers
>>>> Alessio
>>>>
>>> _______________________________________________
>>> jbossws-dev mailing list
>>> jbossws-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbossws-dev
>>
>
>


From asoldano at redhat.com  Mon Jul  7 05:30:01 2014
From: asoldano at redhat.com (Alessio Soldano)
Date: Mon, 07 Jul 2014 11:30:01 +0200
Subject: [jbossws-dev] Fwd: EndpointMetrics Refactor
In-Reply-To: <53BA64D4.4060406@redhat.com>
References: <53B26A36.4080102@redhat.com>
	<53B27357.10102@redhat.com>	<53B41CAC.4080703@redhat.com>
	<53B4CF8E.7060008@redhat.com> <53BA5AFA.5090102@redhat.com>
	<53BA6270.2030708@redhat.com> <53BA64D4.4060406@redhat.com>
Message-ID: <53BA6899.1040201@redhat.com>

On 07/07/14 11:13, Jim Ma wrote:
> These 4 cxf jiras are related to this change:
>   [CXF-5847]:Add operation to enable/disable ResponseTimeCounter
>   [CXF-5843]:Allow define the ObjectName of ResponseTimeCounterMBean
>   [CXF-5840]:ResponseTimeCounter counts the one-way fault message twice
>   [CXF-5839]:ResponseTimeCounter doesn't count the schema validation 
> fault
>
> With the change for this 4 JIRAs, I also did some refactor to log more 
> accurate
> begin/end processing time and clean up work to  remove some unused code.
OK, fine.
I assume those are required and hence we need to consume a cxf version 
including them before eventually merging your branches, right?
Moreover, I see some of the issues above are marked as solved in CXF 
3.1.0, one in 3.0.1. Is that correct?

Thanks
Alessio


>
> Cheers,
> Jim
>
> On 07/07/14 17:03, Alessio Soldano wrote:
>> Thanks,
>> will have a look. Can you clarify which of the jiras on this topic 
>> recently created at https://issues.apache.org are actually required?
>> Thanks
>> Alessio
>>
>> On 07/07/14 10:31, Jim Ma wrote:
>>> I've checked in all things related this change for your review :
>>>
>>> https://svn.jboss.org/repos/jbossws/spi/branches/metrics
>>> https://svn.jboss.org/repos/jbossws/common/branches/metrics
>>> https://svn.jboss.org/repos/jbossws/stack/cxf/branches/metrics
>>> https://github.com/jimma/wildfly/tree/metric
>>> All the cxf change are merged : in 
>>> https://git-wip-us.apache.org/repos/asf/cxf.git
>>>
>>> If you have any concerns and comments, please let me know.
>>>
>>> Thanks,
>>> Jim
>>>
>>> On 03/07/14 11:35, Jim Ma wrote:
>>>> Thanks for all your input, Alessio. I've already created prototype 
>>>> code,
>>>> will create some workspace and check in later.
>>>>
>>>> On 07/02/2014 10:52 PM, Alessio Soldano wrote:
>>>>> Hi Jim,
>>>>>
>>>>>> At the beginning,  I'd like to quickly list the cons of the current
>>>>>> EndpointMetrics
>>>>>> implementation.
>>>>>> - Because the statistics is fulfilled in RequestHandlerImpl , 
>>>>>> after the
>>>>>> response is successfully
>>>>>>        returned to receiver. The response related metric value 
>>>>>> could not
>>>>>> be updated in time, more
>>>>>>        details pleas see JBWS-3808
>>>>>> - It doesn't count the one way fault correctly.
>>>>> yep, we need more consistent values to be returned by metric queries.
>>>>>
>>>>>> - It doesn't expose all the attribute in jmx.
>>>>> This is not necessarily a requirement, but a nice to have.
>>>>>
>>>>>> - If the cxf's management is enabled, user will get two different
>>>>>> statistics value. One is
>>>>>>        calculated  with jbossws-cxf's endpointmetrics which 
>>>>>> happens in
>>>>>> RequestHandler(servlet),
>>>>>>        and another one is calculated with 
>>>>>> ResponseTimeInterceptor(cxf's
>>>>>> interceptor).
>>>>> right, and this is possibly confusing users, while we could rely 
>>>>> on the
>>>>> existing cxf mechanism...
>>>>>
>>>>>
>>>>>> The pros of current implementation :
>>>>>>     - It gives more accurate start time for each request.
>>>>>>     - It is simple and doesn't need to add more interceptor/extra 
>>>>>> code in
>>>>>> the runtime to collect
>>>>>>         the data.
>>>>> In any case, regardless of which solution we eventually end up 
>>>>> relying
>>>>> on, we need to make the data collection as light as possible and, 
>>>>> more
>>>>> important, we need to make sure you can disable statistics and get no
>>>>> performance degradation at all.
>>>>>
>>>>>> >From the above analysis, one important thing we need to do is 
>>>>>> make the
>>>>>> EndpintMetrics seamlessly
>>>>>> work with cxf's management intercetptor and get statistics from one
>>>>>> place instead of generate two
>>>>>> copies from different implementation.
>>>>> +1
>>>>>
>>>>>> There is CounterRepostiry extension in cxf  which responsible for
>>>>>> creating ResponseTimeCounter
>>>>>> for each endpoint,  It can be the only source we get statistics 
>>>>>> for each
>>>>>> endpoint.
>>>>>> To get metric value from this class, we need to change following 
>>>>>> things:
>>>>>> 1. Each ResponseTImeCounter(something similar to EndpointMetrics) is
>>>>>> lazily created in
>>>>>>        message interceptor and put in CounterReposiory with a long
>>>>>> ObjectName at the moment. We
>>>>>>        need to change it and add the ResponseTimeCounter for each 
>>>>>> jbossws
>>>>>> endpoint , then put it in
>>>>>>        CounterRepostiry with key name of endpoint name.
>>>>>> 2. Change EndpointMetricsFactory abstract class to create with
>>>>>> EndpointMetric with endpoint
>>>>>>        parameter so the endpoint name can be used to create
>>>>>> ResponseTimeCounter.
>>>>>> 3. Create new EndpointMetricImpl in jbossws-cxf and get metric value
>>>>>> from ResponseCounter
>>>>>>       which is created for each endpoint.
>>>>>> 4. Change the ResponseTimeInterceptor and allow for define the 
>>>>>> counter
>>>>>> object name.
>>>>>>
>>>>>> Besides this , I also need to refactor the 
>>>>>> ResponseTimeInterceptor to
>>>>>> make it log the process time
>>>>>> more accurate(by move ResponseTimeInInterceptor before several
>>>>>> interceptors ?). And also refactor
>>>>>> the ResponseTimeInterceptor a bit to handle the fault message 
>>>>>> correctly.
>>>>> The plan might work afaics here. The details are probably the core of
>>>>> the issue ;-) I think you can provide a prototype and we can have 
>>>>> a look
>>>>> together. Just always keep in mind my comment above regarding
>>>>> performance and being able to disable the stats at runtime to have 
>>>>> full
>>>>> perf.
>>>>>
>>>>> Cheers
>>>>> Alessio
>>>>>
>>>> _______________________________________________
>>>> jbossws-dev mailing list
>>>> jbossws-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbossws-dev
>>>
>>
>>
>


-- 
Alessio Soldano
Web Service Lead, JBoss


From ema at redhat.com  Mon Jul  7 05:40:18 2014
From: ema at redhat.com (Jim Ma)
Date: Mon, 07 Jul 2014 17:40:18 +0800
Subject: [jbossws-dev] Fwd: EndpointMetrics Refactor
In-Reply-To: <53BA6899.1040201@redhat.com>
References: <53B26A36.4080102@redhat.com>
	<53B27357.10102@redhat.com>	<53B41CAC.4080703@redhat.com>
	<53B4CF8E.7060008@redhat.com> <53BA5AFA.5090102@redhat.com>
	<53BA6270.2030708@redhat.com> <53BA64D4.4060406@redhat.com>
	<53BA6899.1040201@redhat.com>
Message-ID: <53BA6B02.9070805@redhat.com>

On 07/07/14 17:30, Alessio Soldano wrote:
>
> OK, fine.
> I assume those are required and hence we need to consume a cxf version 
> including them before eventually merging your branches, right?
Yes. Alessio. It relies on these change in cxf.
> Moreover, I see some of the issues above are marked as solved in CXF 
> 3.1.0, one in 3.0.1. Is that correct?
These should be all included in cxf 3.0.1. I've updated all these issues 
to resolved and target version is 3.0.1.
>
> Thanks
> Alessio
>
>
>>
>> Cheers,
>> Jim
>>
>> On 07/07/14 17:03, Alessio Soldano wrote:
>>> Thanks,
>>> will have a look. Can you clarify which of the jiras on this topic 
>>> recently created at https://issues.apache.org are actually required?
>>> Thanks
>>> Alessio
>>>
>>> On 07/07/14 10:31, Jim Ma wrote:
>>>> I've checked in all things related this change for your review :
>>>>
>>>> https://svn.jboss.org/repos/jbossws/spi/branches/metrics
>>>> https://svn.jboss.org/repos/jbossws/common/branches/metrics
>>>> https://svn.jboss.org/repos/jbossws/stack/cxf/branches/metrics
>>>> https://github.com/jimma/wildfly/tree/metric
>>>> All the cxf change are merged : in 
>>>> https://git-wip-us.apache.org/repos/asf/cxf.git
>>>>
>>>> If you have any concerns and comments, please let me know.
>>>>
>>>> Thanks,
>>>> Jim
>>>>
>>>> On 03/07/14 11:35, Jim Ma wrote:
>>>>> Thanks for all your input, Alessio. I've already created prototype 
>>>>> code,
>>>>> will create some workspace and check in later.
>>>>>
>>>>> On 07/02/2014 10:52 PM, Alessio Soldano wrote:
>>>>>> Hi Jim,
>>>>>>
>>>>>>> At the beginning,  I'd like to quickly list the cons of the current
>>>>>>> EndpointMetrics
>>>>>>> implementation.
>>>>>>> - Because the statistics is fulfilled in RequestHandlerImpl , 
>>>>>>> after the
>>>>>>> response is successfully
>>>>>>>        returned to receiver. The response related metric value 
>>>>>>> could not
>>>>>>> be updated in time, more
>>>>>>>        details pleas see JBWS-3808
>>>>>>> - It doesn't count the one way fault correctly.
>>>>>> yep, we need more consistent values to be returned by metric 
>>>>>> queries.
>>>>>>
>>>>>>> - It doesn't expose all the attribute in jmx.
>>>>>> This is not necessarily a requirement, but a nice to have.
>>>>>>
>>>>>>> - If the cxf's management is enabled, user will get two different
>>>>>>> statistics value. One is
>>>>>>>        calculated  with jbossws-cxf's endpointmetrics which 
>>>>>>> happens in
>>>>>>> RequestHandler(servlet),
>>>>>>>        and another one is calculated with 
>>>>>>> ResponseTimeInterceptor(cxf's
>>>>>>> interceptor).
>>>>>> right, and this is possibly confusing users, while we could rely 
>>>>>> on the
>>>>>> existing cxf mechanism...
>>>>>>
>>>>>>
>>>>>>> The pros of current implementation :
>>>>>>>     - It gives more accurate start time for each request.
>>>>>>>     - It is simple and doesn't need to add more 
>>>>>>> interceptor/extra code in
>>>>>>> the runtime to collect
>>>>>>>         the data.
>>>>>> In any case, regardless of which solution we eventually end up 
>>>>>> relying
>>>>>> on, we need to make the data collection as light as possible and, 
>>>>>> more
>>>>>> important, we need to make sure you can disable statistics and 
>>>>>> get no
>>>>>> performance degradation at all.
>>>>>>
>>>>>>> >From the above analysis, one important thing we need to do is 
>>>>>>> make the
>>>>>>> EndpintMetrics seamlessly
>>>>>>> work with cxf's management intercetptor and get statistics from one
>>>>>>> place instead of generate two
>>>>>>> copies from different implementation.
>>>>>> +1
>>>>>>
>>>>>>> There is CounterRepostiry extension in cxf  which responsible for
>>>>>>> creating ResponseTimeCounter
>>>>>>> for each endpoint,  It can be the only source we get statistics 
>>>>>>> for each
>>>>>>> endpoint.
>>>>>>> To get metric value from this class, we need to change following 
>>>>>>> things:
>>>>>>> 1. Each ResponseTImeCounter(something similar to 
>>>>>>> EndpointMetrics) is
>>>>>>> lazily created in
>>>>>>>        message interceptor and put in CounterReposiory with a long
>>>>>>> ObjectName at the moment. We
>>>>>>>        need to change it and add the ResponseTimeCounter for 
>>>>>>> each jbossws
>>>>>>> endpoint , then put it in
>>>>>>>        CounterRepostiry with key name of endpoint name.
>>>>>>> 2. Change EndpointMetricsFactory abstract class to create with
>>>>>>> EndpointMetric with endpoint
>>>>>>>        parameter so the endpoint name can be used to create
>>>>>>> ResponseTimeCounter.
>>>>>>> 3. Create new EndpointMetricImpl in jbossws-cxf and get metric 
>>>>>>> value
>>>>>>> from ResponseCounter
>>>>>>>       which is created for each endpoint.
>>>>>>> 4. Change the ResponseTimeInterceptor and allow for define the 
>>>>>>> counter
>>>>>>> object name.
>>>>>>>
>>>>>>> Besides this , I also need to refactor the 
>>>>>>> ResponseTimeInterceptor to
>>>>>>> make it log the process time
>>>>>>> more accurate(by move ResponseTimeInInterceptor before several
>>>>>>> interceptors ?). And also refactor
>>>>>>> the ResponseTimeInterceptor a bit to handle the fault message 
>>>>>>> correctly.
>>>>>> The plan might work afaics here. The details are probably the 
>>>>>> core of
>>>>>> the issue ;-) I think you can provide a prototype and we can have 
>>>>>> a look
>>>>>> together. Just always keep in mind my comment above regarding
>>>>>> performance and being able to disable the stats at runtime to 
>>>>>> have full
>>>>>> perf.
>>>>>>
>>>>>> Cheers
>>>>>> Alessio
>>>>>>
>>>>> _______________________________________________
>>>>> jbossws-dev mailing list
>>>>> jbossws-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jbossws-dev
>>>>
>>>
>>>
>>
>
>


From asoldano at redhat.com  Tue Jul  8 06:45:28 2014
From: asoldano at redhat.com (Alessio Soldano)
Date: Tue, 08 Jul 2014 12:45:28 +0200
Subject: [jbossws-dev] Fwd: EndpointMetrics Refactor
In-Reply-To: <53BA5AFA.5090102@redhat.com>
References: <53B26A36.4080102@redhat.com>
	<53B27357.10102@redhat.com>	<53B41CAC.4080703@redhat.com>
	<53B4CF8E.7060008@redhat.com> <53BA5AFA.5090102@redhat.com>
Message-ID: <53BBCBC8.5050505@redhat.com>

Hi Jim,
here is the feedback on the metrics stuff; please note it's a general 
review on the topic, including both stuff you just implemented and stuff 
being already there in cxf: I'm just trying to evaluate what's there atm 
and see if it fits our needs.

  ResponseTime(*)Interceptor
--------------------------------------
* The AbstractResponseTimeInterceptor#getServiceCounterName method will 
be using the counter name we set in the EndpointAssociationInterceptor, 
good. However, from a CXF point of view, the name could be computed each 
time, so the code doing that needs to be decently optimized. In 
particular, the StringBuilder should be properly used there; if there's 
a StringBuilder being used, you should really avoid string 
concatenations to add stuff in the builder. The JDK optimizer will 
replace the string concatenations with additional StringBuilder 
instances, which is a waste of resources. So basically use multiple 
append() invocations instead of String concatenations (unless the String 
constants only are being concatenated).
* same reasoning for 
AbstractResponseTimeInterceptor#getOperationCounterName, plus please use 
StringBuilder instead of StringBuffer, as that's not accessed concurrently.
* In all ResponseTimeMessage(*)Interceptor, the check on "forceDisabled" 
should come before the isServiceCounterEnabled() invocation, as that's 
expensive. So basically do "if !forceDisabled && 
(isServiceCounterEnabled(ex))" instead of "if 
(isServiceCounterEnabled(ex) && !forceDisabled)"

  ResponseTimeCounter
-------------------------------
* Generally speaking I have some concerns on the thread safety of this 
class, in particular on visibility. Shouldn't we have final or volatile 
attributes?
* At line 87, did you really want to use "|" or "||" ?
* Is it possible to end up with handlingTime = 0 for oneway messages and 
hence end up setting min handling time to 0 ? Is that reasonable ? 
(probably no...)
* the update of min and max handling time in not performed in a thread 
safe way; please have a look at how that should possible be done in our 
former EndpointMetricImpl (see updateMin / updateMax in [1])
* it is possible to get unreliable values for the average response time 
in highly concurrent environments; we might decide to accept this or 
solve as we did in our EndpointMetricsImpl (see the usage or read/write 
lock and related comment in [1])

  EndpointAssociationInterceptor
-------------------------------------------
* We should probably set the service counter name in the exchange only 
when the statistics are enabled.

  EndpointMetricsCXFAdapterImpl
--------------------------------------------
* counterRepo and counter members should be final, while there's no need 
for keeping a reference to the objectName

Thanks
Alessio



[1] 
http://anonsvn.jboss.org/repos/jbossws/common/tags/jbossws-common-2.3.0.Final/src/main/java/org/jboss/ws/common/management/EndpointMetricsImpl.java




On 07/07/14 10:31, Jim Ma wrote:
> I've checked in all things related this change for your review :
>
> https://svn.jboss.org/repos/jbossws/spi/branches/metrics
> https://svn.jboss.org/repos/jbossws/common/branches/metrics
> https://svn.jboss.org/repos/jbossws/stack/cxf/branches/metrics
> https://github.com/jimma/wildfly/tree/metric
> All the cxf change are merged : in 
> https://git-wip-us.apache.org/repos/asf/cxf.git
>
> If you have any concerns and comments, please let me know.
>
> Thanks,
> Jim
>
> On 03/07/14 11:35, Jim Ma wrote:
>> Thanks for all your input, Alessio. I've already created prototype code,
>> will create some workspace and check in later.
>>
>> On 07/02/2014 10:52 PM, Alessio Soldano wrote:
>>> Hi Jim,
>>>
>>>> At the beginning,  I'd like to quickly list the cons of the current
>>>> EndpointMetrics
>>>> implementation.
>>>> - Because the statistics is fulfilled in RequestHandlerImpl , after 
>>>> the
>>>> response is successfully
>>>>        returned to receiver. The response related metric value 
>>>> could not
>>>> be updated in time, more
>>>>        details pleas see JBWS-3808
>>>> - It doesn't count the one way fault correctly.
>>> yep, we need more consistent values to be returned by metric queries.
>>>
>>>> - It doesn't expose all the attribute in jmx.
>>> This is not necessarily a requirement, but a nice to have.
>>>
>>>> - If the cxf's management is enabled, user will get two different
>>>> statistics value. One is
>>>>        calculated  with jbossws-cxf's endpointmetrics which happens in
>>>> RequestHandler(servlet),
>>>>        and another one is calculated with 
>>>> ResponseTimeInterceptor(cxf's
>>>> interceptor).
>>> right, and this is possibly confusing users, while we could rely on the
>>> existing cxf mechanism...
>>>
>>>
>>>> The pros of current implementation :
>>>>     - It gives more accurate start time for each request.
>>>>     - It is simple and doesn't need to add more interceptor/extra 
>>>> code in
>>>> the runtime to collect
>>>>         the data.
>>> In any case, regardless of which solution we eventually end up relying
>>> on, we need to make the data collection as light as possible and, more
>>> important, we need to make sure you can disable statistics and get no
>>> performance degradation at all.
>>>
>>>> >From the above analysis, one important thing we need to do is make 
>>>> the
>>>> EndpintMetrics seamlessly
>>>> work with cxf's management intercetptor and get statistics from one
>>>> place instead of generate two
>>>> copies from different implementation.
>>> +1
>>>
>>>> There is CounterRepostiry extension in cxf  which responsible for
>>>> creating ResponseTimeCounter
>>>> for each endpoint,  It can be the only source we get statistics for 
>>>> each
>>>> endpoint.
>>>> To get metric value from this class, we need to change following 
>>>> things:
>>>> 1. Each ResponseTImeCounter(something similar to EndpointMetrics) is
>>>> lazily created in
>>>>        message interceptor and put in CounterReposiory with a long
>>>> ObjectName at the moment. We
>>>>        need to change it and add the ResponseTimeCounter for each 
>>>> jbossws
>>>> endpoint , then put it in
>>>>        CounterRepostiry with key name of endpoint name.
>>>> 2. Change EndpointMetricsFactory abstract class to create with
>>>> EndpointMetric with endpoint
>>>>        parameter so the endpoint name can be used to create
>>>> ResponseTimeCounter.
>>>> 3. Create new EndpointMetricImpl in jbossws-cxf and get metric value
>>>> from ResponseCounter
>>>>       which is created for each endpoint.
>>>> 4. Change the ResponseTimeInterceptor and allow for define the counter
>>>> object name.
>>>>
>>>> Besides this , I also need to refactor the ResponseTimeInterceptor to
>>>> make it log the process time
>>>> more accurate(by move ResponseTimeInInterceptor before several
>>>> interceptors ?). And also refactor
>>>> the ResponseTimeInterceptor a bit to handle the fault message 
>>>> correctly.
>>> The plan might work afaics here. The details are probably the core of
>>> the issue ;-) I think you can provide a prototype and we can have a 
>>> look
>>> together. Just always keep in mind my comment above regarding
>>> performance and being able to disable the stats at runtime to have full
>>> perf.
>>>
>>> Cheers
>>> Alessio
>>>
>> _______________________________________________
>> jbossws-dev mailing list
>> jbossws-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbossws-dev
>


-- 
Alessio Soldano
Web Service Lead, JBoss


From ema at redhat.com  Wed Jul  9 06:16:20 2014
From: ema at redhat.com (Jim Ma)
Date: Wed, 09 Jul 2014 18:16:20 +0800
Subject: [jbossws-dev] Fwd: EndpointMetrics Refactor
In-Reply-To: <53BBCBC8.5050505@redhat.com>
References: <53B26A36.4080102@redhat.com>
	<53B27357.10102@redhat.com>	<53B41CAC.4080703@redhat.com>
	<53B4CF8E.7060008@redhat.com> <53BA5AFA.5090102@redhat.com>
	<53BBCBC8.5050505@redhat.com>
Message-ID: <53BD1674.1040108@redhat.com>

Hi Alessio,

Thanks for the review! Please see my comments inline.

On 08/07/14 18:45, Alessio Soldano wrote:
>  ResponseTime(*)Interceptor
> --------------------------------------
> * The AbstractResponseTimeInterceptor#getServiceCounterName method 
> will be using the counter name we set in the 
> EndpointAssociationInterceptor, good. However, from a CXF point of 
> view, the name could be computed each time, so the code doing that 
> needs to be decently optimized. In particular, the StringBuilder 
> should be properly used there; if there's a StringBuilder being used, 
> you should really avoid string concatenations to add stuff in the 
> builder. The JDK optimizer will replace the string concatenations with 
> additional StringBuilder instances, which is a waste of resources. So 
> basically use multiple append() invocations instead of String 
> concatenations (unless the String constants only are being concatenated).
  These are all legacy codes from cxf, and another 5 StringBuilder 
instance will be created for the string concatenations. But it is more 
readable than all with append(). Should we pay the additional resources 
to get readability?
> * same reasoning for 
> AbstractResponseTimeInterceptor#getOperationCounterName, plus please 
> use StringBuilder instead of StringBuffer, as that's not accessed 
> concurrently.
   I wrote this wrong. It's a local variable and doesn't have some 
concurrent issue,so StringBuilder will be fine, no need StringBuff.
> * In all ResponseTimeMessage(*)Interceptor, the check on 
> "forceDisabled" should come before the isServiceCounterEnabled() 
> invocation, as that's expensive. So basically do "if !forceDisabled && 
> (isServiceCounterEnabled(ex))" instead of "if 
> (isServiceCounterEnabled(ex) && !forceDisabled)"
  I'll make this change.
>
>  ResponseTimeCounter
> -------------------------------
> * Generally speaking I have some concerns on the thread safety of this 
> class, in particular on visibility. Shouldn't we have final or 
> volatile attributes?
  Looked at this class again.  The totalHandlingTime, minHandlingTime 
and maxHandlingTime should be all atomic variable.
> * At line 87, did you really want to use "|" or "||" ?
  typo !
> * Is it possible to end up with handlingTime = 0 for oneway messages 
> and hence end up setting min handling time to 0 ? Is that reasonable ? 
> (probably no...)
  no. The oneway message will go into several interceptors and consume 
some time to finish the process.
> * the update of min and max handling time in not performed in a thread 
> safe way; please have a look at how that should possible be done in 
> our former EndpointMetricImpl (see updateMin / updateMax in [1])
  It should be all atomic variable here.
> * it is possible to get unreliable values for the average response 
> time in highly concurrent environments; we might decide to accept this 
> or solve as we did in our EndpointMetricsImpl (see the usage or 
> read/write lock and related comment in [1])
   I am not sure if the lock is a bit heavy here. It is possible to 
affect the interceptor execution performance ,  and it will wait the 
lock, then the last interceptor MessageSenderEndingInterceptor can 
really send the response to the client.Do you
   think compareAndSet()  can help solve this problem ?

>
>  EndpointAssociationInterceptor
> -------------------------------------------
> * We should probably set the service counter name in the exchange only 
> when the statistics are enabled.
  I'll refactor this.
>
>  EndpointMetricsCXFAdapterImpl
> --------------------------------------------
> * counterRepo and counter members should be final, while there's no 
> need for keeping a reference to the objectName
   Make it as method local final variable will be better.


Cheers,
Jim


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbossws-dev/attachments/20140709/40cd5cbe/attachment.html 

From asoldano at redhat.com  Fri Jul 11 06:28:48 2014
From: asoldano at redhat.com (Alessio Soldano)
Date: Fri, 11 Jul 2014 12:28:48 +0200
Subject: [jbossws-dev] Fwd: EndpointMetrics Refactor
In-Reply-To: <53BD1674.1040108@redhat.com>
References: <53B26A36.4080102@redhat.com>
	<53B27357.10102@redhat.com>	<53B41CAC.4080703@redhat.com>
	<53B4CF8E.7060008@redhat.com> <53BA5AFA.5090102@redhat.com>
	<53BBCBC8.5050505@redhat.com> <53BD1674.1040108@redhat.com>
Message-ID: <53BFBC60.9070002@redhat.com>

Hi Jim,

On 09/07/14 12:16, Jim Ma wrote:
> On 08/07/14 18:45, Alessio Soldano wrote:
>>  ResponseTime(*)Interceptor
>> --------------------------------------
>> * The AbstractResponseTimeInterceptor#getServiceCounterName method 
>> will be using the counter name we set in the 
>> EndpointAssociationInterceptor, good. However, from a CXF point of 
>> view, the name could be computed each time, so the code doing that 
>> needs to be decently optimized. In particular, the StringBuilder 
>> should be properly used there; if there's a StringBuilder being used, 
>> you should really avoid string concatenations to add stuff in the 
>> builder. The JDK optimizer will replace the string concatenations 
>> with additional StringBuilder instances, which is a waste of 
>> resources. So basically use multiple append() invocations instead of 
>> String concatenations (unless the String constants only are being 
>> concatenated).
>  These are all legacy codes from cxf, and another 5 StringBuilder 
> instance will be created for the string concatenations. But it is more 
> readable than all with append(). Should we pay the additional 
> resources to get readability?
To me yes, we should, I believe it's worth the additional readability 
cost. But we can do this as a separate task in the next future, if you 
prefer.

>> * same reasoning for 
>> AbstractResponseTimeInterceptor#getOperationCounterName, plus please 
>> use StringBuilder instead of StringBuffer, as that's not accessed 
>> concurrently.
>   I wrote this wrong. It's a local variable and doesn't have some 
> concurrent issue,so StringBuilder will be fine, no need StringBuff.
Good, I see you already fixed this.


>> * In all ResponseTimeMessage(*)Interceptor, the check on 
>> "forceDisabled" should come before the isServiceCounterEnabled() 
>> invocation, as that's expensive. So basically do "if !forceDisabled 
>> && (isServiceCounterEnabled(ex))" instead of "if 
>> (isServiceCounterEnabled(ex) && !forceDisabled)"
>  I'll make this change.
As above, fixed, good.

>>
>>  ResponseTimeCounter
>> -------------------------------
>> * Generally speaking I have some concerns on the thread safety of 
>> this class, in particular on visibility. Shouldn't we have final or 
>> volatile attributes?
>  Looked at this class again.  The totalHandlingTime, minHandlingTime 
> and maxHandlingTime should be all atomic variable.
Sure, for atomic changes. Moreover, since you're setting all the 
attributes with default starting values, add a 'final' to all of them to 
explicitly ensure visibility.

>> * At line 87, did you really want to use "|" or "||" ?
>  typo !
;-)

>> * Is it possible to end up with handlingTime = 0 for oneway messages 
>> and hence end up setting min handling time to 0 ? Is that reasonable 
>> ? (probably no...)
>  no. The oneway message will go into several interceptors and consume 
> some time to finish the process.
OK

>> * the update of min and max handling time in not performed in a 
>> thread safe way; please have a look at how that should possible be 
>> done in our former EndpointMetricImpl (see updateMin / updateMax in [1])
>  It should be all atomic variable here.
Right, as commented above.

>> * it is possible to get unreliable values for the average response 
>> time in highly concurrent environments; we might decide to accept 
>> this or solve as we did in our EndpointMetricsImpl (see the usage or 
>> read/write lock and related comment in [1])
>   I am not sure if the lock is a bit heavy here. It is possible to 
> affect the interceptor execution performance ,  and it will wait the 
> lock, then the last interceptor MessageSenderEndingInterceptor can 
> really send the response to the client.Do you
>   think compareAndSet()  can help solve this problem ?
For sure any lock can add some delay; the idea is that the R/W lock 
mechanism could basically prevent threads recording the response time 
from blocking, unless someone is getting the average response time at 
the same time (as the access to the average would use the W lock). Some 
profiling / perf test could confirm the actual impact.
Compare and set (CAS) is of no use here, imho, because you need the 
result of 2 independent method invocations (retrieval of 
totalHandlingTime value and invocation number value).

>>
>>  EndpointAssociationInterceptor
>> -------------------------------------------
>> * We should probably set the service counter name in the exchange 
>> only when the statistics are enabled.
>  I'll refactor this.
OK, thanks

>>
>>  EndpointMetricsCXFAdapterImpl
>> --------------------------------------------
>> * counterRepo and counter members should be final, while there's no 
>> need for keeping a reference to the objectName
>   Make it as method local final variable will be better.
>
OK

Cheers
Alessio

-- 
Alessio Soldano
Web Service Lead, JBoss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbossws-dev/attachments/20140711/cf8824da/attachment.html 

From ema at redhat.com  Tue Jul 15 23:21:38 2014
From: ema at redhat.com (Jim Ma)
Date: Wed, 16 Jul 2014 11:21:38 +0800
Subject: [jbossws-dev] Fwd: EndpointMetrics Refactor
In-Reply-To: <53BFBC60.9070002@redhat.com>
References: <53B26A36.4080102@redhat.com>
	<53B27357.10102@redhat.com>	<53B41CAC.4080703@redhat.com>
	<53B4CF8E.7060008@redhat.com> <53BA5AFA.5090102@redhat.com>
	<53BBCBC8.5050505@redhat.com> <53BD1674.1040108@redhat.com>
	<53BFBC60.9070002@redhat.com>
Message-ID: <53C5EFC2.8080408@redhat.com>

On 07/11/2014 06:28 PM, Alessio Soldano wrote:
>
>>> * it is possible to get unreliable values for the average response 
>>> time in highly concurrent environments; we might decide to accept 
>>> this or solve as we did in our EndpointMetricsImpl (see the usage or 
>>> read/write lock and related comment in [1])
>>   I am not sure if the lock is a bit heavy here. It is possible to 
>> affect the interceptor execution performance ,  and it will wait the 
>> lock, then the last interceptor MessageSenderEndingInterceptor can 
>> really send the response to the client.Do you
>>   think compareAndSet()  can help solve this problem ?
> For sure any lock can add some delay; the idea is that the R/W lock 
> mechanism could basically prevent threads recording the response time 
> from blocking, unless someone is getting the average response time at 
> the same time (as the access to the average would use the W lock). 
> Some profiling / perf test could confirm the actual impact.
> Compare and set (CAS) is of no use here, imho, because you need the 
> result of 2 independent method invocations (retrieval of 
> totalHandlingTime value and invocation number
I thought AtomicReference's CAS with the generic object which contains 
totalTime and invocation count could help, but it has to make the object 
final and construct a large number of this object, it's not a ideal. I 
back to look at the solution with one lock and refactor the 
ResponseTimeCounter#increase(). After did some performance tests, it 
looks the ReentrantLock is good  and  it didn't slow down the thing too 
much.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbossws-dev/attachments/20140716/da97c9c0/attachment-0001.html