[ https://issues.apache.org/jira/browse/CASSANDRA-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979758#comment-13979758 ]
Benedict commented on CASSANDRA-6106: ------------------------------------- Well, what I should have made clear is that I am willing to drop the monotonicity guarantees, however I am -1 on your extra thread. But I still think the monotonicity guarantees are good, and not so difficult to prove, so if we can get somebody who doesn't have a newborn to contend with to take a look maybe that wouldn't be a bad thing :) In case it helps, here's a quick proof we can never give a whack value: {noformat} 1. -100000<= adjustMicros<=100000 2. expire-adjustFrom=1000000000 2a. expireMicros-adjustFromMicros=1000000 3. adjustFromMicros<=micros<=expireMicros 4. delta = (adjustMicros * (micros-adjustFromMicros)) / (expireMicros-adjustFromMicros) 5. 2a ^ 3 ^ 4 -> expireMicros-adjustFromMicros > micros-adjustFromMicros -> |delta| <= |adjustMicros| {noformat} i.e. the adjustment is definitely always less than adjustMicros, which is itself always less than 100ms per second (per 1 and 2). So we can never give a totally whack result. Can do more thorough proofs of other criteria, but I think this plus my other statement is enough to demonstrate its safety. > 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)