<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 07/11/2014 06:28 PM, Alessio Soldano
wrote:<br>
</div>
<blockquote cite="mid:53BFBC60.9070002@redhat.com" type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
<br>
<blockquote cite="mid:53BD1674.1040108@redhat.com" type="cite">
<blockquote cite="mid:53BBCBC8.5050505@redhat.com" type="cite">*
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]) <br>
</blockquote>
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 <br>
think compareAndSet() can help solve this problem ?<br>
</blockquote>
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.<br>
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<br>
</blockquote>
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. <br>
</body>
</html>