[ 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