Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 8 Sep 2015 16:39:46 +0000 (UTC)
From: "Yuki Morishita (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12862474.1441730365000.280450.1441730386994@Atlassian.JIRA>
In-Reply-To: <JIRA.12862474.1441730365000@Atlassian.JIRA>
References: <JIRA.12862474.1441730365000@Atlassian.JIRA>
 <JIRA.12862474.1441730365988@arcas>
Subject: [jira] [Created] (CASSANDRA-10283) Create central class that
 represents node's local data store
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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)