[
https://issues.apache.org/jira/browse/CASSANDRA-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780287#comment-13780287
]
Sylvain Lebresne commented on CASSANDRA-6106:
---------------------------------------------
bq. if a new node comes on, I don't think we want to require that it have
access to a "quorum" of nodes in order to accept writes
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. Also, nothing
forces use to use the number of total nodes for the replication factor of the
table that will hold that node->id map (like what we do for system_auth, we
might want a special keyspace to control the RF). In any case, I hardly think
it's a blocker.
bq. I think it is much simpler to exploit the fact that when two nodes are
talking, they already have plenty of context for determining who should win.
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.
bq. Then you don't have to store anything extra with each cell.
Given that conflict resolution is done at the cell level and can be done at
basically any time after the initial writes, I'm not really sure how that's
possible (unless you rewrite Cassandra completely of course, but it seems we
agree it's not worth creating a new system).
bq. The best you could do
Wanna bet? :)
> 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
