[
https://issues.apache.org/jira/browse/CASSANDRA-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799267#comment-13799267
]
Christopher Smith commented on CASSANDRA-6106:
----------------------------------------------
Hey, since 1.2.11 is going out without this issue resolved, wanted to see what
the thinking was. While Cassandra ships with JNA, it isn't strictly a
*requirement*, so I think using nanoTime, perhaps with periodic recalibration
would be preferable. Maybe you could go with JNA with the currentTimeMillis()
fallback, but that basically will mean JNA has to be there on any setup that
needs concurrent update resolution, all because of issues with one platform
(Windows).
What about my alternative of using random data for the lower bits? It could be
done the same way TimeUUID works, which would go a long way to making
collisions statistically unlikely without imposing any potential Windows
slowdown.
> 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, 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.1#6144)
