You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jason Brown (JIRA)" <ji...@apache.org> on 2017/12/12 16:44:00 UTC
[jira] [Commented] (CASSANDRA-14108) Improve commit log chain
marker updating
[ https://issues.apache.org/jira/browse/CASSANDRA-14108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16287856#comment-16287856 ]
Jason Brown commented on CASSANDRA-14108:
-----------------------------------------
Branches and tests here:
||3.0||3.11||trunk||
|[branch|https://github.com/jasobrown/cassandra/tree/13987-followup-3.0]|[branch|https://github.com/jasobrown/cassandra/tree/13987-followup-3.11]|[branch|https://github.com/jasobrown/cassandra/tree/13987-followup-trunk]|
|[utests & dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/13987-followup-3.0]|[utests & dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/13987-followup-3.11]|[utests & dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/13987-followup-trunk]|
||
I've removed the confusing (and confusingly described) yaml property for setting the {{commitlog_marker_period_in_ms}}. Instead, I've hardcoded the marker interval to 100ms and it is always applied when a) using periodic mode, and b) not using compression or encryption.
I've fixed the bug that @ariel found by quantizing the {{commitlog_sync_period_in_ms}} to a multiple of the marker interval. At the worst, this would change the {{commitlog_sync_period_in_ms}} by up to 50 ms. I don't think anyone will really notice those milliseconds at a practical level, and if they do, they should be using batch or group mode.
I've also refactored {{AbstractCommitLogService}} so we can actually unit test it. The anonymous {{Runnable}} class that had 90% of the functionality of {{AbstractCommitLogService}} is now a full-fledged, named, and accessible nested class, {{AbstractCommitLogService.SyncRunnable}}. To avoid being bound by actual wall clock timings for correctness testing, {{AbstractCommitLogService.SyncRunnable}} is using the {{Clock}} abstraction; this makes testing sane, safe, and repeatable. {{Clock}} was introduced in CASSANDRA-12016, and committed to 3.10. I've backported it to 3.0, but I feel it's quite safe and doesn't affect anything outside of itself.
> Improve commit log chain marker updating
> ----------------------------------------
>
> Key: CASSANDRA-14108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14108
> Project: Cassandra
> Issue Type: Bug
> Reporter: Jason Brown
> Assignee: Jason Brown
> Fix For: 4.x
>
>
> CASSANDRA-13987 addressed the commit log behavior change that was introduced with CASSANDRA-3578. After that patch was committed, [~aweisberg] did his own review and found a bug as well as having some concerns about the configuration. He and I discussed offline, and agreed on some improvements.
> Instead of requiring users to configure a deep, dark implementation detail like the commit log chained markers (via {{commitlog_marker_period_in_ms}} in the yaml), we decided it is best to eliminate thew configuration and always update the chained markers (when in periodic mode).
> The bug [~aweisberg] found was when the chained marker update is not a value that evenly divides into the periodic sync mode value, we would not sync in an expected manner. For example if the marker interval is 9 seconds, and the sync interval is 10 seconds, we would update the markers at time9, but we would then sleep for another 9 seconds, and when we wake up at time18, it is then that we flush - 8 seconds later than we should have.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org