[
https://issues.apache.org/jira/browse/CASSANDRA-9649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14602599#comment-14602599
]
Stefania commented on CASSANDRA-9649:
-------------------------------------
bq. The problem is that this ends up potentially modifying the UUIGen clock, so
a big clock skew of a node in the future can now "screw up" any generated time
UUID in other nodes, which is scary. The idea being just getting back to the no
arg UUIDGen.getTimeUUID() is that it's the simplest thing that is basically
guaranteed to not create any unintended consequence for other parts of the
code. All we're giving up is CASSANDRA-5667 but that was "just an optimization"
in the first place.
I see, thanks for the explanation. I force pushed a commit to revert back to
getTimeUUID(). Is this enough or do we need to revert the entire change
introduced by CASSANDRA-5667?
bq. It doesn't have to because the only method that ever read/modify it is
synchronized (I don't know if much though went into doing it this way rather
than using an atomic long (and no synchronized method) but I do know that such
considerations are out of scope for this ticket )
Agreed.
> Paxos ballot in StorageProxy could clash
> ----------------------------------------
>
> Key: CASSANDRA-9649
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9649
> Project: Cassandra
> Issue Type: Bug
> Reporter: Stefania
> Assignee: Stefania
> Priority: Minor
>
> This code in {{StorageProxy.beginAndRepairPaxos()}} takes a timestamp in
> microseconds but divides it by 1000 before adding one. So if the summary is
> null, ballotMillis would be the same for up to 1000 possible state timestamp
> values:
> {code}
> long currentTime = (state.getTimestamp() / 1000) + 1;
> long ballotMillis = summary == null
> ? currentTime
> : Math.max(currentTime, 1 +
> UUIDGen.unixTimestamp(summary.mostRecentInProgressCommit.ballot));
> UUID ballot = UUIDGen.getTimeUUID(ballotMillis);
> {code}
> {{state.getTimestamp()}} returns the time in micro seconds and it ensures to
> add one microsecond to any previously used timestamp if the client sends the
> same or an older timestamp.
> Initially I used this code in {{ModificationStatement.casInternal()}},
> introduced by CASSANDRA-9160 to support cas unit tests, but occasionally
> these tests were failing. It was only when I ensured uniqueness of the ballot
> that the tests started to pass reliably.
> I wonder if we could ever have the same issue in StorageProxy?
> cc [~jbellis] and [~slebresne] for CASSANDRA-7801
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
