cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6106) Provide timestamp with true microsecond resolution
Date Thu, 24 Apr 2014 12:31:21 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979644#comment-13979644
] 

Sylvain Lebresne commented on CASSANDRA-6106:
---------------------------------------------

Sorry but I still find it a tad more complicated that what we really need (I'll note that
I really don't want us to screw up timestamps due to some rounding error or whatnot, which
is why I rather strongly care about simplicity). I'm probably stupid, but I still need to
sit with a pen and paper a few minutes to understand the arithmetic, check there is not edge
case not handled and even still, I can't totally convince myself that the whole adjusting
business really provide us practical benefits (given how timestamps are used) over just brute
forcing monotonity like we currently do in QueryState in the rare cases clocks go slightly
backward. But for the record, I'll say on the patch that:
* QueryState#getTimestamp would need to be changed or this isn't actually used by user queries.
* I don't totally reconcile saying that {{clock_gettime}} is a bit slow, but still having
it call on a query thread, even if it's only once per second (which is not even guaranteed
because once the validUntilNanos expires, multiple thread might fight over updating the spec).
Especially when, if the call is slow for some reason, we incur an even greater cost by retrying
the call up to 3 times. Not a huge problem I suppose, but not too ideal in my book.

So anyway, I've pushed at https://github.com/pcmanus/cassandra/commits/6106_alternative what
I think is a simpler yet sufficient solution, so that I'd rather go with that (unless there's
an obvious big problem with it I've missed).  


> Provide timestamp with true microsecond resolution
> --------------------------------------------------
>
>                 Key: CASSANDRA-6106
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6106
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>         Environment: DSE Cassandra 3.1, but also HEAD
>            Reporter: Christopher Smith
>            Assignee: Benedict
>            Priority: Minor
>              Labels: timestamps
>             Fix For: 2.1 beta2
>
>         Attachments: microtimstamp.patch, microtimstamp_random.patch, microtimstamp_random_rev2.patch
>
>
> I noticed this blog post: http://aphyr.com/posts/294-call-me-maybe-cassandra mentioned
issues with millisecond rounding in timestamps and was able to reproduce the issue. If I specify
a timestamp in a mutating query, I get microsecond precision, but if I don't, I get timestamps
rounded to the nearest millisecond, at least for my first query on a given connection, which
substantially increases the possibilities of collision.
> I believe I found the offending code, though I am by no means sure this is comprehensive.
I think we probably need a fairly comprehensive replacement of all uses of System.currentTimeMillis()
with System.nanoTime().



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message