[jira] [Updated] (CASSANDRA-10283) Create central class that represents node's local data store
[
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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10283) Create central class that represents node's local data store
[
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: Local Write-Read Paths
> 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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
