[
https://issues.apache.org/jira/browse/CASSANDRA-21662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict Elliott Smith updated CASSANDRA-21662:
-----------------------------------------------
Resolution: Fixed
Status: Resolved (was: Triage Needed)
> Accord executor QoS and incremental execution
> ---------------------------------------------
>
> Key: CASSANDRA-21662
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21662
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Accord
> Reporter: Benedict Elliott Smith
> Assignee: Benedict Elliott Smith
> Priority: Normal
>
> Accord executor QoS and incremental execution
> QoS: Tasks are categorised so that their relative arrival/service rate can be
> tracked by
> 7-bit decaying counters. Work may be assigned by a mixture of highest
> priority task or
> least-serviced queue by a deficit round-robin scheme. This prevents e.g.
> cache flushes
> from dominating executor threads.
> Incremental Execution: Implementation fully implements enriched ASYNC/INCR
> ExecutionContext
> semantics, so that tasks may be decomposed into multiple steps with
> optional ATOMIC isolation.
> This permits sync points in particular to be processed in smaller batches,
> allowing smaller
> non-conflicting tasks to interleave.
> Also Improve:
> * Continuation tasks allow declaring work that logically continues prior
> work, and that must
> execute before treating the initiating task as complete (distinct from
> notifying any callback);
> Continuation or partial incremental tasks that fail with ATOMIC visibility
> mark a key as unavailable
> to prevent reading inconsistent state.
> * Consequences of tasks are submitted as part of the task's completion
> * Consequences of durable tasks that fail are cancelled before they are
> submitted
> * Handle partial task failure: propagate failure to counting results instead
> of silently
> decrementing, and abandon dependent continuations.
> * ExclusiveExecutor releases its lock eagerly, opening up
> tryExecuteImmediately to more executions
> * Memtables blocking an Accord durability status update will be flushed
> periodically
> * NoSpamLogger.NoDuplicateSpamLogStatement: rate-limit per distinct exception
> * Claude-generated formal specification of execution semantics under
> formalise/accord/execution
> * AutoRepair shutdown executors simultaneously, and terminate running
> sessions
> * Shutdown UDF and SASI executors
> * FailureDetector: pass Double.MAX_VALUE on forceConvict to ensure listeners
> process an explicit shutdown
> Also Fix:
> * Data races updating Task.info (between executing thread and executor lock
> owner)
> * AccordExecutor/ThreadLocalTaskRunner lock accounting could be corrupted on
> shutdown
> * SignalLock incorrectly limited signals to MAX_THREADS not MAX_SIGNAL_COUNT
> (throwing an exception)
> * SignalLock invisible bug in tryAcquireAsyncInAwaitLoop
> * Reject negative histogram values (LogLinearHistogram,
> LogLinearDecayingHistograms), and ensure callers do not submit
> * RepairOption.permitNoQuorum() returned repairAccord instead of
> permitNoQuorum.
> * FailureDetector: do not convict endpoints already marked down, since
> Accord may become active while marked !isAlive;
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
