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.