[jira] [Updated] (CASSANDRA-10283) Create central class that represents node's local data store

["C. Scott Andreas (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-10283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

C. Scott Andreas updated CASSANDRA-10283:
-----------------------------------------
    Component/s: Core

> Create central class that represents node's local data store
> ------------------------------------------------------------
>
>                 Key: CASSANDRA-10283
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10283
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core, Local Write-Read Paths
>            Reporter: Yuki Morishita
>            Priority: Minor
>              Labels: refactoring
>             Fix For: 4.x
>
>
> This is related to CASSANDRA-7837 which aims to take down static initializations and singletons. Instead of doing it all at once, we can / should conquer by dividing internal to several part as discussed in that ticket. I just throw in my thought to discuss further.
> The node local data store (commitlog, memtable, SSTable etc) is at the core of Cassandra, and I think it is good to start from here.
> The central class for local data store class (I refer it as {{CassandraDataStore}} from here) manages the following:
> * CommitLog
> * CacheService
> * IndexSummaryManager
> * Keyspace / ColumnFamilyStore
> * CompactionManager
> * Schema / SchemaKeyspace
> * MemtablePool
> and possibly others, basically those that don't use {{MessagingService}}. These classes won't have static initialization/accessors and singleton, as {{CassandraDataStore}} initializes and wires them as necessary. We also can take access to {{DatabaseDescriptor}} away from these classes as {{CassandraDataStore}} does initialization (but this can be done separately).
> Of course, even after this, we still need to have one singleton instance that is {{CassandraDataStore}} itself to be accessed from other modules, but it will eventually be gone as we take down other part of singletons.
> Benefits to do this includes:
> * More explicit startup and cleanup procedure. It is hard to tell what is initialized when right now, and sometimes it creates unpredected result.
> * Simpler unit test setup. We don't need to bootstrap messaging or gossip to test local only functionality.
> Even the scope of the change is limitted compare to CASSANDRA-7837, this needs a lot of effort still and change to the code is still huge. But I believe this is worth the shot, and I appreciate any feedbacks regarding feasibility.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org