Stefania created CASSANDRA-9649:
-----------------------------------
Summary: 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)
