[
https://issues.apache.org/jira/browse/CASSANDRA-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-6106:
--------------------------------------
Description:
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().
was:
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().
There seems to be some confusion here, so I'd like to clarify: the purpose of
this patch is NOT to improve the precision of ordering guarantees for
concurrent writes to cells. The purpose of this patch is to reduce the
probability that concurrent writes to cells are deemed as having occurred at
*the same time*, which is when Cassandra violates its atomicity guarantee.
> 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
