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.