[jbossws-dev] Fwd: EndpointMetrics Refactor

[Jim Ma]

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