[jira] [Comment Edited] (CASSANDRA-5704) Truncate flushes to disk again in 1.2, even with durable_writes=false

["Christian Spriegel (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13694036#comment-13694036 ] 

Christian Spriegel edited comment on CASSANDRA-5704 at 6/26/13 9:09 PM:
------------------------------------------------------------------------

{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 also 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.

                
      was (Author: christianmovi):
    {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: https://issues.apache.org/jira/browse/CASSANDRA-5704
>             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(cfs.table.name);
> +        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: http://www.atlassian.com/software/jira