cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Created] (CASSANDRA-10558) Fix out-of-order scrub test
Date Wed, 21 Oct 2015 08:15:27 GMT
Sylvain Lebresne created CASSANDRA-10558:

             Summary: Fix out-of-order scrub test
                 Key: CASSANDRA-10558
             Project: Cassandra
          Issue Type: Sub-task
            Reporter: Sylvain Lebresne
            Assignee: Yuki Morishita
             Fix For: 3.0.0

This is kind of a followup of CASSANDRA-9880.

As the name imply, the out-of-order scrub test ({{ScrubTest.testScrubOutOfOrder}}) test scrubs
detects a sstable with out-of-order partitions, which imply we have a generated sstable with
out of order partitions. That latter part being not trivial since we have a sanity check in
{{BigTableWriter}} that we never write out-of-order partitions. And hence, generating such
a sstable used to be manual: you had to comment the check in {{BigTableWriter}} and uncomment
some code in {{ScrubTest}} to generate the sstable. That did imply you had to manually regenerate
the sstable each time the sstable format was changed.

I had do to such manipulation in CASSANDRA-9705 (as there was some change to the sstable format)
and unfortunately I screwed up and included the uncommenting of the sanity check in {{BigTableWriter}}
in the commit.

In the meantime, came CASSANDRA-9880, which aimed to make the manual process of generating
out-of-order sstable automatic. Unfortunately, that ticket was done with the {{BigTableWriter}}
sanity check commented, which did make things a lot easier for the test, but was kind of wrong.

So anyway, commenting the check in {{BigTableWriter}} was an oversight and I uncommented it
on the cassandra-3.0/trunk branches. The problem is that {{ScrubTest.testScrubOutOfOrder}}
now fails due to that check. We need to find a way to make that test work without disabling
our sanity check on writes. Not sure what's the best solution though to be honest. Maybe we'll
need a flag in {{BigTableWriter}} to disable that check just for the test?

This message was sent by Atlassian JIRA

View raw message