[
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)
