[
https://issues.apache.org/jira/browse/CASSANDRA-9649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14602587#comment-14602587
]
Sylvain Lebresne commented on CASSANDRA-9649:
---------------------------------------------
bq. I modified UUIDGen.getTimeUUID(long when) to do the same thing as the
override without any arguments.
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.
bq. One thing that is not clear to me is why isn't UUIDGen.lastNanos an atomic
long?
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 :))
> 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)
