[jira] [Commented] (CASSANDRA-6106) Provide timestamp with true microsecond resolution

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

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

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

I'd like to summarize my understanding of what we're trying to fix here.

As far as conflict resolution goes, microsecond resolution is imo rather useless. Given the accuracy of ntp, network latencies and whatnot, no application should ever rely on sub-milliseconds resolution for conflicts, and any application that rely on fine-grained ordering of updates to a cell should really provide client-side timestamp. It doesn't mean we can't use microsecond resolution if it's easy of course, but does mean that imo the bar on what complexity is worth it is rather low.

This was not the original motivation of this ticket however. The original motivation was to limit the chance of 2 updates A and B getting the exact same timestamp, because when that happens, we could end up with some cell from A and some cell from B. I think we all agreed that the proper fix for that was more complicated and left to CASSANDRA-6123. Yet, as I said earlier, since that fix is much more complicated, I'm fine lowering the chances of timestamp conflicts in the meantime if that's easy for us (less often broken is somewhat better than more often broken, even if not broken is obviously better). But for this point, Christopher solution of randomizing the microseconds bits was actually really simple and probably good enough.

And to be honest, Benedict's branch complexity is above what I consider reasonable for the concrete problem at hand. I'm surely not very smart, but it doesn't fit my own definition of straightforward. I'm not saying that it's the most complicated thing ever, but it's complicated enough to make me uncomfortable, given that even some simple rounding error on the timestamp could basically destroy user data.

I'm also not convinced we need that complexity in practice. What about just having a thread call clock_gettime followed by nanoTime every second or so, and then just add the nano time between now and the last time clock_gettime was called to get the current time. It might not be perfect to get the most and best timestamp we can, but it's imo largely good enough for our purpose (and for clocks going back in time, we already handle that in a brute force kind of way in QueryState, which is again imo good enough).

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