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