[
https://issues.apache.org/jira/browse/CASSANDRA-6920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13959334#comment-13959334
]
Benedict commented on CASSANDRA-6920:
-------------------------------------
Do we really need the synchronized block? Just because it has no measurable
performance impact in this test, or now, doesn't mean it won't in future, and
taking that penalty on every operation just to guard an infrequent read
operation seems really unpleasant to me. Also, it affects profiling output (has
a tendency to erroneously indicate it as a CPU sink).
At the very least we should be using a ReadWriteLock to make sure we don't put
threads to sleep for no good reason, but frankly I'd say simply checking that
ops != lastOpCount would suffice on read. If they're the same return 0 and
don't update the numbers, otherwise do what we were always doing before. Or
have the reader spin until it sees two consistent values. Any of the above
would be preferable to putting new places for threads to fall asleep on the
read/write path (I am on a slow burning mission to eliminate thread signalling
costs)
> LatencyMetrics can return infinity
> -----------------------------------
>
> Key: CASSANDRA-6920
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6920
> Project: Cassandra
> Issue Type: Bug
> Reporter: Nick Bailey
> Assignee: Nick Bailey
> Fix For: 1.2.17, 2.0.7, 2.1 beta2
>
> Attachments: 6920-cassandra-1.2.patch, 6920-cassandra-2.0.patch,
> 6920-infinity-metrics.patch
>
>
> There is a race condition when updating the recentLatency metrics exposed
> from LatencyMetrics.
> Attaching a patch with a test that exposes the issue and a potential fix.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
