cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (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 Mon, 21 Oct 2013 09:46:42 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800513#comment-13800513
] 

Sylvain Lebresne commented on CASSANDRA-6106:
---------------------------------------------

bq. since 1.2.11 is going out without this issue resolved

I'm not against targeting 2.0 but this won't go into the 1.2 branch as this is really just
an improvement.

bq. What about my alternative of using random data for the lower bits?

I don't think we want to do that because at the very least we want to keep the behavior that
timestamp generated for the same client connection are always strictly increasing, and it
seems to me that randomizing is not really compatible with it.

bq. nanoTime, perhaps with periodic recalibration

It's an option, though I'll admit that it feels a bit like a hack. Not totally opposed I guess,
but as Jonathan, I think I'd be fine with using gettimeofday and leaving platform that don't
support it with the status quo.

Though on the longer run, I'm starting to be convinced that we should slowly move back to
client side timestamps by default (CASSANDRA-6178) so it's unclear to me how much effort is
worth putting into this (given that, at the end of the day, this won't ensure timestamp uniqueness
anyway and you'd still have to be aware that on timestamp tie, the resolution is based on
the value).


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