[
https://issues.apache.org/jira/browse/CASSANDRA-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13779602#comment-13779602
]
Christopher Smith commented on CASSANDRA-6106:
----------------------------------------------
Regarding the "could be 100 micros in to the current ms, we could be 900, we
have no way to tell".
That is correct. There is no way, with Java, to have a universal timestamp
across nodes that is guaranteed to be ordered properly at a precision less than
2 milliseconds.
However, given that the wobble in network latency is generally >= 1 millisecond
*anyway*, that is FAR less of a concern. If a client wants to ensure which of
two writes happens first, it probably can't use server side timestamps.
The big concern is the chance that two concurrent writes which have two or more
overlapping cells be assigned the same timestamp. This is a *real risk* for any
app with lots of concurrent writes to the same cells, regardless of its time
sensitivity.
> 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
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
