[ https://issues.apache.org/jira/browse/CASSANDRA-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13955416#comment-13955416 ]
Christopher Smith commented on CASSANDRA-6106: ---------------------------------------------- Isn't using gettimeofday or clock_gettime crossing the "custom JNI code" rubicon anyway? > QueryState.getTimestamp() & FBUtilities.timestampMicros() reads current > timestamp with System.currentTimeMillis() * 1000 instead of System.nanoTime() > / 1000 > ------------------------------------------------------------------------------------------------------------------------------------------------------------ > > 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)