[
https://issues.apache.org/jira/browse/CASSANDRA-14062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16279168#comment-16279168
]
Jeff Jirsa commented on CASSANDRA-14062:
----------------------------------------
I suspect one of the fundamental differences between other pluggable interfaces
like (row cache, compaction, replication strategies, partitioners), and the
commitlog, is that the commitlog really MUST interact with an awful lot of the
internals to be even remotely functional.
If we actively try to allow for third party pluggable commitlogs, one of the
main concerns seems to be how we guarantee that we don't break your commitlog
in a minor version - Keyspace, Mutation, PartitionUpdate, SerializationHelper -
those are all private internal APIs, and they change FREQUENTLY. It seems very
likely that we'd break your implementation frequently, and potentially in very
subtle ways that may not be user-obvious.
I **really** want to find a way to make this work, but I think Ariel's concern
here is real - if we update PartitionUpdate from 4.0.0 to 4.0.1, your jar for
4.0.0 may break in a horrible way, and I don't think we can commit to not
changing those interfaces - the exposure surface is huge, we can't give up that
much optionality. Depending primarily on CommitLogReplayer as a way to minimize
that exposure sounds like something worth investigating.
> Pluggable CommitLog
> -------------------
>
> Key: CASSANDRA-14062
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14062
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Rei Odaira
> Assignee: Rei Odaira
> Labels: features
> Fix For: 4.x
>
> Attachments: pluggable-commitlog-src.patch,
> pluggable-commitlog-test.patch
>
>
> This proposal is to make CommitLog pluggable, as discussed in [the Cassandra
> dev mailing
> list|https://lists.apache.org/thread.html/1936194d86f5954fa099ced9a0733458eb3249bff3fae3e03e2d1bd8@%3Cdev.cassandra.apache.org%3E].
> We are developing a Cassandra plugin to store CommitLog on our low-latency
> Flash device (CAPI-Flash). To do that, the original CommitLog interface must
> be changed to allow plugins. Synching to CommitLog is one of the performance
> bottlenecks in Cassandra especially with batch commit. I think the pluggable
> CommitLog will allow other interesting alternatives, such as one using SPDK.
> Our high-level design is similar to the CacheProvider framework
> in org.apache.cassandra.cache:
> * Introduce a new interface, ICommitLog, with methods like
> getCurrentPosition(), add(), shutdownBlocking(), etc.
> * CommitLog implements ICommitLog.
> * Introduce a new interface, CommitLogProvider, with a create() method,
> returning ICommitLog.
> * Introduce a new class FileCommitLogProvider implementing CommitLogProvider,
> to return a singleton instance of CommitLog.
> * Introduce a new property in cassandra.yaml, commitlog_class_name, which
> specifies what CommitLogProvider to use. The default is
> FileCommitLogProvider.
> * Introduce a new class, CommitLogHelper, that loads the class specified by
> the commitlog_class_name property, creates an instance, and stores it to
> CommitLogHelper.instance.
> * Replace all of the references to CommitLog.instance with
> CommitLogHelper.instance.
> Attached are two patches. "pluggable-commitlog-src.patch" is for changes in
> the src directory, and "pluggable-commitlog-test.patch" is for the test
> directory.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
