[
https://issues.apache.org/jira/browse/CASSANDRA-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979722#comment-13979722
]
Sylvain Lebresne commented on CASSANDRA-6106:
---------------------------------------------
bq. it's still much better than without it, if that's your only concern?
I'm not afraid of slight microseconds imprecision that wouldn't matter, I'm
afraid of returning a timestamp that is completely broken on some edge case,
and the more arithmetic is going on, the more risk there is. Sure we can double
and triple check the math to convince ourself, it's just that I don't think
your solution bring any real benefits in practice "for conflict-resolution
timestamps" over my proposition, and I think my solution is conceptually
simpler, and I think we should always go for simpler when we can, and I think
we can.
Now, I've discussed my view on the ticket itself (which I still halfway think
could be closed as won't fix since at the end of the day the real problem for
which it was opened is really CASSANDRA-6123), and on you branch (for which I
don't see the point of "getting comfortable with the math" when there is a
simpler solution imo) enough. I don't see much to add at this point. I'm not
vetoing your solution, I just can't +1 it when I think my solution is a tad
better (because simpler). Let's have someone else look at it and formulate an
opinion, probably I'm just being difficult for lack of sleep.
> Provide timestamp with true microsecond resolution
> --------------------------------------------------
>
> 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
> Assignee: Benedict
> Priority: Minor
> Labels: timestamps
> Fix For: 2.1 beta2
>
> 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.2#6252)
