[jira] [Resolved] (CASSANDRA-9568) commit_sync: batch either doesn't work or has confusing documentation

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-9568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Ellis resolved CASSANDRA-9568.
---------------------------------------
       Resolution: Invalid
    Reproduced In: 2.2.0 rc1, 2.1.6, 2.0.16  (was: 2.1.6, 2.0.16, 2.2.0 rc1)

The commitlog allocates its storage in files called "segments," which are created with a constant size and "filled up" as writes come in.  This has the dual benefit of avoiding fragmentation on spinning disks and allowing us to use the less expensive fdatasync when writing updates, as opposed to full fsync which has to journal the new file length as well.

> commit_sync: batch either doesn't work or has confusing documentation
> ---------------------------------------------------------------------
>
>                 Key: CASSANDRA-9568
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9568
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jim Witschey
>
> Based on the language [here|http://docs.datastax.com/en/cassandra/2.1/cassandra/configuration/configCassandra_yaml_r.html?scroll=reference_ds_qfg_n1r_1k__commitlog_sync], I thought that when {{commitlog_sync}} was set to {{batch}}, inserts would block until the commitlog was written to and fsynced. As the docs say,
> {quote}
> When using this method, writes are not acknowledged until fsynced to disk.
> {quote}
> This doesn't seem to be the case. I've pushed a failing dtest [here|https://github.com/riptano/cassandra-dtest/compare/master...mambocab:commitlog_sync-batch-bug] demonstrating the behavior; even after writing thousands of rows, the size of the commitlog doesn't change. I see similar values when measuring the commitlog size via JMX, so I don't believe it's a measurement error on my part. I see this behavior on trunk and on HEAD for 2.2, 2.1, and 2.0.
> This should either be fixed, or the behavior should be more clearly documented. I asked about the intended behavior in #cassandra and didn't get an answer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)