Status

Current state: "Withdrawn" - Each ticket will be considered individually, rather than being considered together in the CEP.

Discussion thread: here

JIRAs:

  • Unable to render Jira issues macro, execution error.
  • Unable to render Jira issues macro, execution error.
  • Unable to render Jira issues macro, execution error.
  • More Coming

Released: Unreleased

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Currently there are many internal subsystems with fixed implementations.  As has already been seen from CEP-10 there are advantages to being able to plug in alternative implementations for testing, or for trying out new implementations, without disrupting the existing implementation.  We are proposing to add the ability to swap about the implementations of more internal systems beyond those proposed in CEP-10 to further improve those abilities.

Audience

Cassandra Developers 

Goals

Improve the ability to use alternate implementations of different subsystems to improve their modularity/testability/mockability.  CEP-10 and CEP-15 have already started this process for some subsystems, the goal here is to continue in a similar vein for Schema Storage, Cluster Membership, Compaction <-> SStable interactions, Failure Detection, and Messaging Service Verbs.

Non-Goals

This proposal is not to replace all uses of singletons, or completely refactor all internal APIs.

Approach

Refactor internal APIs around Schema Storage, Cluster Membership, Compaction <-> SStable interactions, Failure Detection, and Messaging Service Verbs to improve pluggability and testability.

Proposed Changes

The following subsystems will gain the ability to have a new implementation provided.

  • Schema - Encapsulate schema storage and synchronization through a generic interface that can be mocked out for testing or replaced to test new implementations.
  • Cluster Membership - Encapsulate token metadata access through a generic interface that can be mocked out for testing or replaced to test new implementations. 
  • Compaction <-> SStable interactions - Encapsulate interactions between compaction strategies and the underlying sstables through a generic interface that can be mocked out for testing or replaced to test new implementations.
  • Failure Detection - Convert FailureDetector into a generic interface that can be mocked out for testing or replaced to test new implementations.

New or Changed Public Interfaces

By default there should be no “Application Developer” visible changes to interfaces.  There may be new config properties for specifying alternate implementations to use for some of the subsystems.  These would be available for operators to try out alternate implementations or for Apache Cassandra Developers to use when developing tests.

  • Schema - Create new interfaces for interacting with schema and schema updates.
  • Cluster Membership - Create a new interface for accessing token metadata.
  • Compaction <-> SStable interactions - Create new interfaces for compaction strategies to access sstable information.
  • Failure Detection - Convert the FailureDetector class into a mockable interface.

Compatibility, Deprecation, and Migration Plan

  • No impact on existing behavior.  The changes are code refactoring to ease future development and should not change any existing behavior by default.

Test Plan

New tests will be added for all changed interfaces to compliment existing tests ensuring that there is no change in behavior when the default implementations are used.



  • No labels