Cassandra resolves pluggable extensions by class name from configuration, schema, and tooling
inputs. These names were loaded with an initializing Class.forName(name) and type-checked only
afterward, so the named class ran its static initializer before its type was confirmed. After this
change such classes will be loaded without initialization, verified against the expected interface or
base class, and initialized only through normal use after validation.
A shared FBUtilities.classForNameWithoutInitialization helper and typed
instanceOrConstruct/construct overloads apply this to the configurable extension points loaded by
class name: the authentication, authorization, role-management, network and
internode-authenticator backends, the partitioner, audit logger, configuration loader, seed provider,
snitch, abstract types, secondary and custom indexes, compaction strategy, compressor, replication
strategy, SASI analyzers, key and cache providers, query handler, storage and stream hooks, tracing,
the JMX authorization proxy, MBeans, the monotonic clock, nodetool Sjk, triggers, the
sstableloader and stress class options, and diagnostic event classes (loaded without initialization
and checked against DiagnosticEvent, preserving the InvalidClassException contract and the existing
package restriction).
Regression tests confirm that an invalid-type load is rejected without initializing the target
class, and that valid implementations still resolve.
Hadoop client integration and hard-coded JDK and internal class probes are left unchanged.
patch by Jeremiah Jordan; reviewed by Stefan Miklosovic for CASSANDRA-21525
Restore deleteCDCRawFiles logic which is present in 6.0 and trunk but probably lost in 5.0 due to merges
Files may be concurrently removed by the CDC management thread, so we tolerate a file that has already been deleted rather than failing the test.
Fix IndexOutOfBoundsException at commitlog.AbstractCommitLogSegmentManager.forceRecycleAll - it is already fixed in 6.0/trunk.
Cleanup test data after run to reduce disk usage.
Patch by Dmitry Konstantinov; reviewed by Michael Semb Wever for CASSANDRA-20091
SEPExecutor.maybeExecuteImmediately() runs a task synchronously on the
calling worker thread, nested within the task the worker is already
running. Such immediate tasks were invisible in system_views.queries, which only exposed each worker's primary running task.
This is common on the coordinator path, where a local read or mutation is executed immediately within the enclosing QUERY task.
Each SEPWorker now also tracks an immediate current task, set around
maybeExecuteImmediately(), and exposes it as an additional
DebuggableTaskRunner, so the queries table reports both the enclosing
task and the immediate one as separate rows.
patch by Dmitry Konstantinov; reviewed by Caleb Rackliffe for CASSANDRA-21471
Patch by Sam Tunnicliffe and Dmitry Konstantinov; reviewed by Sam
Tunnicliffe and Dmitry Konstantinov for CASSANDRA-21384
Co-authored-by: Dmitry Konstantinov <netudima@gmail.com>
Stefan Miklosovic