[jira] [Resolved] (CASSANDRA-6106) Provide timestamp with true microsecond resolution
[ https://issues.apache.org/jira/browse/CASSANDRA-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict resolved CASSANDRA-6106. - Resolution: Won't Fix It was decided that v3 protocol implementors should ensure their timestamps are high precision, since this is the default source of timestamps going forwards. 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: 3.0 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.3.4#6332)
[jira] [Resolved] (CASSANDRA-6106) Provide timestamp with true microsecond resolution
[ https://issues.apache.org/jira/browse/CASSANDRA-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict resolved CASSANDRA-6106. - Resolution: Duplicate 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: 3.0 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.3.4#6332)
