[jbossws-dev] Fwd: EndpointMetrics Refactor

[Jim Ma]

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