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)