cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Smith (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6106) QueryState.getTimestamp() & FBUtilities.timestampMicros() reads current timestamp with System.currentTimeMillis() * 1000 instead of System.nanoTime() / 1000
Date Fri, 18 Oct 2013 16:40:45 GMT

    [ 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)

Mime
View raw message