cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6920) LatencyMetrics can return infinity
Date Thu, 03 Apr 2014 22:17:41 GMT


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:
>             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

View raw message