[
https://issues.apache.org/jira/browse/CASSANDRA-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14111456#comment-14111456
]
Jason Brown edited comment on CASSANDRA-7837 at 8/26/14 10:18 PM:
------------------------------------------------------------------
[~appodictic] how far did you get on CASSANDRA-6881? At a minimum, if we're
serious about "killing the damn singletons" this time, we should merge these
two tickets, depending on how far Ed got.
I'll open a ticket for the Gossiper work as a subtask of either ticket.
was (Author: jasobrown):
[~appodictic] how far did you get on CASSANDRA-6881? At a minimum, if we're
serious about "killing the damn singletons" this time, we should the these two
tickets, depending on how far Ed got.
I'll open a ticket for the Gossiper work as a subtask of either ticket.
> Factor out static initialization / singletons
> ---------------------------------------------
>
> Key: CASSANDRA-7837
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7837
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Blake Eggleston
>
> I've been spending some time experimenting with ways to factor out static
> initialization and static singletons in Cassandra.
> This is a known issue, with obvious implications on testability and
> extensibility. It also leads to subtle changes in behavior of the database
> and tests, as access patterns to static methods reorder the initialization
> order of the static state. For instance, the test
> org.apache.cassandra.config.DatabaseDescriptorTest.testKSMetaDataSerialization
> is no longer testing anything, because Schema.getKeyspaceDefinitions() is
> now returning an empty array. Once the initialization order is changed, the
> test fails because system keyspaces aren't being filtered out, and fromThrift
> throws an exceptions when it sees LocalStrategy. Removing static state and
> singletons will make testing each component in isolation easier, leading to
> fewer regressions.
> With a large refactor like this, we'd want to avoid having the refactor
> branch, and the trunk branch diverging too far, or for too long. After a few
> failed attempts, I've worked out a way to perform the refactor in a way that
> can be performed with a series of (relatively) small patches, and avoid a
> big, scary merge. Each patch will build, the tests will pass, and can be
> merged into trunk daily/regularly as they are completed.
> The process is as follows:
> # Condense all static state into static singletons.
> (DatabaseDescriptor.getPartitioner() ->
> DatabaseDescriptor.instance.getPartitioner())
> ** In some cases, classes will need to be split into pairs of instance and
> factory classes, like in the case of Keyspace and ColumnFamilyStore
> # Identify all non-singleton usages of static state (grep for '.instance.'),
> and refactor to pass dependencies into their constructors from their
> instantiating services.
> # Work out and implement an initialization order for the singletons,
> preferring final members passed into their constructor, using volatile
> members assigned during startup where there are circular dependencies.
> ** We should consider splitting some of the singletons into more component
> specific classes before this step. There is definitely a case for making that
> another ticket, but with the non-singleton dependencies clearly defined at
> this point, we will have a clear idea of what can be split up. Doing that
> would reduce the number of circular dependencies between singletons, and make
> this stage a lot easier, with the additional benefit of further modularizing
> the code.
> # Remove static singleton instances. Initialize and start C* from a static
> method that takes a configuration as an argument.
> ** CassandraDaemon and utilities will need to be updated, and we'll need a
> helper method so tests can instantiate the database with a one or two liner.
> Obviously, this is a lot of work, but I think it's worth the effort. I've
> already gone through a few practice runs, and it's doable. I'm happy to do
> the work, with guidance and input from the C* team.
> Thoughts?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
