[
https://issues.apache.org/jira/browse/CASSANDRA-5014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13694816#comment-13694816
]
Sylvain Lebresne commented on CASSANDRA-5014:
---------------------------------------------
bq. PS: getSnapshot().getValue(retryPolicy.value) returns percentile in
milliseconds
Are you sure? Because the latency in LatencyMetrics is created by
{noformat}
Metrics.newTimer(factory.createMetricName(namePrefix + "Latency"),
TimeUnit.MICROSECONDS, TimeUnit.SECONDS);
{noformat}
which has microseconds as "duration unit", and an (admittedly quick) reading of
the Yammer metrics sources suggests that the Snapshot returned by getSnapshot()
returns value in the "duration unit". So the version before the patch looks
correct to me.
But other than that, v2 lgtm.
> Convert timeout from milli second to micro second.
> --------------------------------------------------
>
> Key: CASSANDRA-5014
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5014
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.0 beta 1
> Reporter: Vijay
> Assignee: Vijay
> Priority: Trivial
> Fix For: 2.0 beta 1
>
> Attachments: 0001-CASSANDRA-5014.patch, 0001-CASSANDRA-5014-v2.patch
>
>
> Convert all the timeouts to microseconds.
> Jonathan's comment from CASSANDRA-4705
> {quote}
> millis may be too coarse a grain here, especially for Custom settings.
> Currently an in-memory read will typically be under 2ms and it's quite
> possible we can get that down to 1 if we can purge some of the latency
> between stages. Might as well use micros since Timer gives it to us for free
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
