You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Marcin Szymaniuk (JIRA)" <ji...@apache.org> on 2014/12/09 13:24:12 UTC
[jira] [Assigned] (CASSANDRA-8440) Refactor StorageProxy
[ https://issues.apache.org/jira/browse/CASSANDRA-8440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcin Szymaniuk reassigned CASSANDRA-8440:
-------------------------------------------
Assignee: Marcin Szymaniuk
> Refactor StorageProxy
> ---------------------
>
> Key: CASSANDRA-8440
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8440
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Joshua McKenzie
> Assignee: Marcin Szymaniuk
> Fix For: 3.0
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)