Cassandra 19503 #84
Cassandra 19503 #84
Conversation
…ge txn and instead uses the sync point empty txn for reads
…so rewrote those to use a new createIllegalState method
| void contact(Set<Node.Id> nodes, Topologies topologies, Callback<GetMaxConflictOk> callback) | ||
| { | ||
| node.send(nodes, to -> new GetMaxConflict(to, topologies, route, keysOrRanges, executionEpoch)); | ||
| node.send(nodes, to -> new GetMaxConflict(to, topologies, route, keysOrRanges, executionEpoch), callback); |
There was a problem hiding this comment.
the fact this happened implies that burn test doesn't hit this code path, so should be something we think about adding... C* hits this all the time as we don't have a max applied, so we would block forever
| // TODO (expected): implement abort | ||
| } | ||
|
|
||
| public static class FetchRequest extends WaitUntilAppliedAndReadData |
There was a problem hiding this comment.
there was a TODO to merge these 2 so I went ahead and did that
| public static class FetchRequest extends ReadData | ||
| { | ||
| private static final ExecuteOn EXECUTE_ON = new ExecuteOn(Applied, Applied); | ||
| public final PartialTxn read; |
There was a problem hiding this comment.
honestly I kept this PartialTxn because it didn't impact anything and I needed to get green before really thinking about it... We only actually care about accord.api.Read so would be a trivial refactor to switch to that
|
|
||
| TopologyMismatch tm = TopologyMismatch.checkForMismatch(snapshot.get(maxEpoch).global(), select); | ||
| EpochState maxState = snapshot.get(maxEpoch); | ||
| Invariants.checkState(maxState != null, "Unable to find epoch %d; known epochs are %d -> %d", maxEpoch, snapshot.minEpoch(), snapshot.currentEpoch); |
There was a problem hiding this comment.
in C* we bootstrap with epoch=9 but there are pending txn in epoch=8... this means that we are failing to handle those txn and SimpleProgressLog starts spamming us... I tried to look at how to add historic epochs but it was getting a bit annoying and didn't actually impact the bootstrap tests... so figured I could delay that problem to another patch
| { | ||
| default: throw new AssertionError(); | ||
| case Key: | ||
| if (!keys.contains((Key)key)) |
There was a problem hiding this comment.
the main reason bootstrap regression failed to be detected in burn test was that it switched to using the sync point's emptyTxn, which has 0 keys... since ListRead supports ranges it was able to return the data requested from bootstrap even though its inputs were outside of the range of keys... This check helps protect that from happening again.
belliottsmith
force-pushed
the
trunk
branch
2 times, most recently
from
6a9482b to
4a8566a
Compare
belliottsmith
force-pushed
the
trunk
branch
9 times, most recently
from
c3a1d8f to
efc6a38
Compare
belliottsmith
force-pushed
the
trunk
branch
3 times, most recently
from
289d5ea to
064735b
Compare
belliottsmith
force-pushed
the
trunk
branch
2 times, most recently
from
2edc7fb to
a271897
Compare
belliottsmith
force-pushed
the
trunk
branch
2 times, most recently
from
50d6ef9 to
bd0761c
Compare
belliottsmith
force-pushed
the
trunk
branch
2 times, most recently
from
183d5d0 to
cd7f495
Compare
1 participant
No description provided.