Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 8 Jul 2011 09:01:19 +0000 (UTC)
From: "Sylvain Lebresne (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: 
 <319016112.10674.1310115679135.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Created] (CASSANDRA-2872) While dropping and recreating an
 index, incremental snapshotting can hang
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

While dropping and recreating an index, incremental snapshotting can hang 
--------------------------------------------------------------------------

                 Key: CASSANDRA-2872
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2872
             Project: Cassandra
          Issue Type: Bug
          Components: Core
    Affects Versions: 0.7.4
            Reporter: Sylvain Lebresne
            Priority: Minor


When creating a hard link (at list with JNA), link() hang if the target of the
link already exists. In theory though, we should not hit that situation
because we use a new directory for each manual snapshot and the generation
number of the sstables should prevent this from hapenning with increment
snapshot.

However, when you drop, then recreate a secondary index, if the sstables are
deleted after the drop and before we recreate the index, the recreated index
sstables will start with a generation to 0. Thus, when we start backuping them
incrementally, it will conflict with the sstables of the previously dropped
index.

First, we should check for the target existance because calling link() to at
least avoid hanging. But then we must make sure that when we drop, then
recreate an index, we will either not name the sstables the same way or the
incremental snapshot use a different directory.


--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira