[
https://issues.apache.org/jira/browse/CASSANDRA-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780318#comment-13780318
]
Christopher Smith commented on CASSANDRA-6106:
----------------------------------------------
{quote}
Given the fact we can persist the ID, the only time we'd constraint a node is
when it is first bootstrapped before fully joining the ring.
{quote}
True.
{quote}
What do you mean exactly by "when two nodes are talking"? What exact moment of
Cassandra inner working are you referring to? Surely you can't be talking of
anything related to the write path since 2 updates that conflicts (have the
same timestamp) can be in 2 completely separate partitions. So I'm not sure I
follow.
{quote}
Good question, and I apologize for not being clear. I was referring to when a
cell's data is being replicated from one node to another.
If the cluster becomes partitioned, there is no need to deal with matching
timestamps on two separate writes in the two different partitions until such
time as the partition ends and you are repairing (indeed, before then you can't
even be aware of the matter). When that time comes, it eventually devolves to
two nodes exchanging information on two cells. That is the context where I
thought a simple heuristic could ensure writes are treated atomically.
{quote}
Wanna bet? :-)
{quote}
Almost want to... not because I think I'd win the bet, but because I know all
too well that sooner or later I'd lose, and we'd have a better system. ;-)
> 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
