cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuki Morishita (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CASSANDRA-10283) Create central class that represents node's local data store
Date Tue, 08 Sep 2015 16:39:46 GMT
Yuki Morishita created CASSANDRA-10283:
------------------------------------------

             Summary: 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
            Reporter: Yuki Morishita
            Priority: Minor
             Fix For: 3.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
(v6.3.4#6332)

Mime
View raw message