- Fix notifying unmanaged after update redundant before/bootstrap
- Do not infer invalid if we have a single round of replies with minKnown not decided and maxKnown erased - in this case store the knowledge for next request.
- Fix SyncPoint topology selection
- Fix CheckStatusOkFull.with(InvalidIf)
- Fix NotifyWaitingOn
- ExecuteTxn should only contact latest topology for follow-up requests
- DurableBefore.min should not go backwards on new epoch topology, journal replay was not correctly handling PreApplied, partialTxn can be null if not owned
- Fix notify pre-bootstrap that arrives post-bootstrap
- Avoid GC race condition on Propagate where we can incorrectly infer a shard is stale
- Ensure redundantBefore on previously-owned range does not imply redundant before for overlapping queries on still-owned range
- Ensure we don't mark stale unless all of the quorum we contacted had erased, else we may have raced with the agreement and erase
- Fix Invalidate when no route found for FetchData does not report to all requested local epochs
- Fix WAS_OWNED_RETIRED without durableBefore at Universal can lead to assertions with RX that we permit to execute but that have not yet
- Fix initialiseWaitingOn can in some cases transitively notify the command we're updating via maybeCleanup of dependencies, but the command isn't yet updated so isn't ready
- Fix encountering a command that is pre-bootstrap, and for which we have locally 'applied' a supserseding RX, so that we do not know its outcome locally (so we do not cleanup the command), but also it must have been decided - and we should not respond with future dependencies.
- Epoch failures on CoordinatePreAccept should trigger the CoordinatePreAccept failure handler
- Use the shard bound rather than GC bound for fallback dependency
- LatestDeps should be sliced to actual route, so as not to use both PreAccepted AND Stable deps as though Stable
- Fix various callback issues with node.withEpoch and Recover/Propose.isDone
- RecoverWithRoute can encounter a partially truncated transaction where the Deps for one shard are not committed. Must fetch LatestDeps.
- Tighten LatestDeps semantics for Recover
- CommandsForKey: do not restore pruned as APPLIED
- Ensure prune points execute in the epoch in which they are declared
- must merge all fast path votes including those from earlier epochs that may have witnessed a later transaction
- Recoveries that know the transaction is committed a priori should skip the Accept phase
- Maintain GC behaviour for redundant commands that are pre-bootstrap
- don't apply ERASE to CommandsForKey to avoid breaking pruning
- Introduce clearBefore to ProgressLog to more consistently handle cleaning up redundant transactions (and avoid triggering burn test invariants)
- don't replay journal of a bootstrapping node in burn test
- Recover, Accept or Commit reply from epoch that has been retired should be treated as Success rather than Redundant
- Distinguish completely REDUNDANT+PRE_BOOTSTRAP from partially GC_BEFORE and REDUNDANT+PRE_BOOTSTRAP - latter can make stronger inferences based on the GC_BEFORE intersection (could perhaps be treated as simply GC_BEFORE)
- RX must register historical transactions with CFK
- CommandStore.bootstrapper must wait for coordinate sync via same mechanism as sync()
- Don't start topology change for shard where all replicas are already bootstrapping
- Reify executes et al in StoreParticipants
- LocalListeners txn listener reentry may erase the entry entirely
- use registerAt in AbstractRequest for expirations, use correct time for expiresAt in ListAgent
- use txnId.epoch() for pruning, as must be before both txnId and executeAt of prune point for coordinating dependencies
- compute accurate KnownMap when affected by bootstrap or staleness
- upgradeTruncated should calculate Definition and Deps separately
- Invalidate should not sort before Erased when calculating max reply or max knowledge reply
- avoid another infinite loop at end of burn test
- avoid another epoch loading edge case
- pass through low/high epochs to ensure we propagate information to all waiting command stores
- RX must adopt a non-pruned dependency that has a higher TxnId (if is itself behind prune point)
- rejects should also be calculated on COMMITTED started before
- remove Apply Factory wrapper for RX, redundant now we have CoordinationAdapters (and has faulty epoch logic)
- for RX ensure we return maximum writes for each epoch we intersect (same effectively as pruning logic)
- rework updateUnmanaged to improve clarity
- BeginRecovery constructor of LatestDeps should use touches() not owns() for compute localDeps
- BeginRecovery superseding calculation was incorrectly treating startedBefore Committed and Accepted the same, when the point at which a dep should be known differs
- Refactor Command visiting, porting C* integration to accord-core
- RelationMultiMap Builder should resize keys and keyLimits independently
- CommandsForKey Serialization moved to accord-core
- losing ownership of range should trigger re-registration of unmanaged waiting on commit of a no-longer owned txn
patch by Benedict; reviewed by Alex Petrov for CASSANDRA-20172
* Move serializers that previously were in static field into corresponding swappable accessors
* Add a (no-op in Cassandra impl) Result serializer
* Allow more than one Accord Journal table
* Move some previously-Cassandra implementation details (such as FieldUpdates) to Accord
* Fix a bug with sorting of Journal Key (incorrect non-identity flags)
* Accord side: Make sure not to re-sort collection of events scheduled for application
* Implement serializers for Accord/BurnTest List* items
Patch by Alex Petrov; reviewed by Benedict Elliott Smith for CASSANDRA-20112.
For correctness, the dependencies we adopt on joining a new topology must exclude the possibility of respondents accepting additional transactions with a lower TxnId, so proxying on the existing `ExclusiveSyncPoint` mechanisms is logical for the time-being. This patch removes the `FetchMajorityDeps` logic in favour of simply waiting for a suitable `ExclusiveSyncPoint` to be proposed.
patch by Benedict, reviewed by Alex Petrov for CASSANDRA-20056
Patch by Alex Petrov; reviewed by Ariel Weisberg for CASSANDRA-20032
Accord Deps tests have incorrect range semantics
patch by David Capwell; reviewed by Ariel Weisberg for CASSANDRA-20029
update durability scheduling and majority deps fetching
do not deserialize deps in CommandsForRangesLoader unless required
AccordJournalPurger should use shouldCleanupPartial
load historical transactions when loading topology
split JournalKey in journal table so we can index it
reorder journal fields so we can easily index on route (when present)
use Message.expiresAtNanos for callback expiration
do not notify slow for range barriers
Accord: Do not contact faulty replicas, and promptly report slow replies for preaccept/read. Do not wait for stale or left nodes for durability.
* reconstruct CFK, TFK, progressLog
* migrate CommandStore collection state from Accord table to the log
* make memtable writes non-durable; reconstruct memtable state from Writes
Patch by Alex Petrov and Benedict Elliott Smith; reviewed by Benedict Elliott Smith and Alex Petrov for CASSANDRA-19869
(Accord): C* stores table in Range which will cause ranges to be removed from Accord when DROP TABLE is performed
patch by David Capwell, Sam Tunnicliffe; reviewed by Sam Tunnicliffe for CASSANDRA-18675
CEP-15: (Accord) sequence EpochReady.coordinating to allow syncComplete to be learned from newer epochs
patch by David Capwell; reviewed by Alex Petrov, Blake Eggleston for CASSANDRA-19769
The SimpleProgressLog had a number of problems:
1. It polled for progress with no attempt to determine whether progress could realistically be made, so:
- as the number of pending transactions grew, the proportion of useful work dropped (as many would be unable to make progress without earlier transactions completing)
- each transaction in the chain could recover only on average 1/2 poll interval behind the last transaction to complete
2. It requested full transaction state from every replica on each attempt
3. It maintained a lot of in-memory state
4. Polling happened en-masse, allowing for little per-transaction control
We also separately maintained fairly expensive per-command listener state that negatively affected our command loading and caching.
The new DefaultProgressLog makes use of several new features: LocalListeners, RemoteListeners, Timers and Await messages.
- LocalListeners provide a memory-efficient collection for managing each CommandStore<E2><80><99>s transaction listeners, with dedicated record keeping for inter-transaction relationships.
- RemoteListeners provide a mechanism for request/response pairs that may be separated by longer than the normal Cassandra message timeout, and require minimal state on sender and recipient. This permits replicas to cheaply update their local state machine as soon as distributed information becomes available.
The DefaultProgressLog tracks each transaction with separate timers to handle per-transaction scheduling, backoff etc, and a succinct state machine. To reduce overhead correspondence is preferentially limited to a handful of replicas, and limited to the home shard where appropriate.
patch by Benedict; reviewed by Ariel Weisberg for CASSANDRA-19870
- Remove concept of non-participating home keys; home keys are required to be a participant in the transaction
- Remove covering/covers concept
- Various invalidation/truncation/erase behaviours
patch by Benedict; reviewed by Blake for CASSANDRA-19825
CommandsForKey periodically self-prunes, so as to continue functioning well in-between garbage collections. Once we prune we are left with potentially incomplete information, and have to sometimes load per-command information from disk. But the payoff is ensuring CommandsForKey objects - which drive the majority of the state machine - are kept to a reasonable size.
patch by Benedict; reviewed by Blake Eggleston and David Capwell
Alex Petrov