[CASSANDRA-8440] Refactor StorageProxy

• Type: Improvement
• Status: Open
• Priority: Normal
• Resolution: Unresolved
• Fix Version/s: 5.x
• Component/s: Legacy/Local Write-Read Paths
• Assignee: Unassigned
• Reporter: Joshua McKenzie
• Created: 08/Dec/14 19:57
• Updated: 07/Mar/23 10:54

Description

The StorageProxy is currently a monolithic singleton with a collection of static methods. This ticket will track a multi-phase effort to refactor this into appropriate subclasses, convert the internals to asynchronous operations, and eventually change the API to being async.

See CASSANDRA-7392 for an example of a feature that this change would help facilitate.

Broken down into 5 phases:

• Phase 1: Un-singleton and Break static methods down into classes
• Phase 2: Convert StorageProxy classes to futures, keep internal synchronous processing so interface doesn't change
• Phase 3: Track count and limits on internal messages within StorageProxy
• Phase 4: Push async interface upstream
• Phase 5: Profile garbage generation from StorageProxy changes and consider object pooling

Granularity with the breakdown above is to make reviews less painful and make it easier to add unit-testing for this component as we go.

Issue Links

• depends upon: CASSANDRA-8099 Refactor and modernize the storage engine
• is duplicated by: CASSANDRA-6985 ReadExecutors should not rely on static StorageProxy
• is related to: CASSANDRA-5239 Asynchronous (non-blocking) StorageProxy

Sub-Tasks

• Phase 1: Break static methods into classes: Open