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