[ https://issues.apache.org/jira/browse/CASSANDRA-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christopher Smith updated CASSANDRA-6106: ----------------------------------------- Attachment: microtimstamp.patch Here's proposed patch to HEAD that fixes at least the two cases I found immediately. Uses currentTimeMillis() & nanoTime() to get a precise but calibrated time stamp. > 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: Bug > Components: Core > Environment: DSE Cassandra 3.1, but also HEAD > Reporter: Christopher Smith > Priority: Minor > Labels: collision, conflict, timestamp > Attachments: microtimstamp.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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira