[
https://issues.apache.org/jira/browse/CASSANDRA-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14111548#comment-14111548
]
Blake Eggleston commented on CASSANDRA-7837:
--------------------------------------------
You mean the guice entry in build.xml? I played around with it initially, but
never ended up doing anything with it. All the dependencies are passed into the
constructors manually.
> 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)
