cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6106) Provide timestamp with true microsecond resolution
Date Thu, 24 Apr 2014 13:36:18 GMT


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

View raw message