cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Spriegel (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5704) Truncate flushes to disk again in 1.2, even with durable_writes=false
Date Wed, 26 Jun 2013 15:45:20 GMT


Christian Spriegel commented on CASSANDRA-5704:

{quote}"Data that was supposed to be gone, could reappear" which feels semantically different
to me.{quote}
I can understand that. My thought was that durable_writes already applies to deletes. So I
thought why not also apply that pattern to truncate?

I could live with a new "test.mode" property though (in cassandra.yaml, right?). I would even
go as far to say that this one should deactivate all fsyncs in Cassandra :-)

Nevertheless, for practical reasons I like the idea of using the durable_writes flag, because
it allows me to use have different behaviour on my dev-laptop for...
- ... one keyspace for my junits. These require constant truncation.
- ... my local installation of our application. Here I like a bit more data safety, because
I not want to set up my testdata all the time.

> Truncate flushes to disk again in 1.2, even with durable_writes=false
> ---------------------------------------------------------------------
>                 Key: CASSANDRA-5704
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.5
>            Reporter: Christian Spriegel
>            Assignee: Christian Spriegel
>            Priority: Minor
>             Fix For: 1.2.7
>         Attachments: CASSANDRA_5704_V1_1_2.patch, CASSANDRA_5704_V1_trunk.patch
> I just upgraded my dev-environment to C* 1.2. Unfortunetaly 1.2 makes my JUnit tests
slow again, due to a blocking-flush in saveTruncationRecord().
> With Cassandra 1.1 truncate was very fast due to: CASSANDRA-4153
> My proposal is to make saveTruncationRecord() only flush when durableWrites are enabled.
> My assumption is that if somebody turn off durable writes then he does not mind if truncate
is not guaranteed to be durable either.
> I successfully tested the following patch with my testsuite. Its as fast as it was with
1.1 (maybe even faster!):
> {code}
> @@ -186,5 +186,8 @@ public class SystemTable
>          String req = "UPDATE system.%s SET truncated_at = truncated_at + %s WHERE key
= '%s'";
>          processInternal(String.format(req, LOCAL_CF, truncationAsMapEntry(cfs, truncatedAt,
position), LOCAL_KEY));
> -        forceBlockingFlush(LOCAL_CF);
> +        
> +        KSMetaData ksm = Schema.instance.getKSMetaData(;
> +        if (ksm.durableWrites) // flush only when durable_writes are enabled
> +            forceBlockingFlush(LOCAL_CF);
>      }
> {code}

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message