Return-Path: X-Original-To: apmail-cassandra-commits-archive@www.apache.org Delivered-To: apmail-cassandra-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id F19DF1018E for ; Thu, 17 Oct 2013 15:05:46 +0000 (UTC) Received: (qmail 14749 invoked by uid 500); 17 Oct 2013 15:05:46 -0000 Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org Received: (qmail 14706 invoked by uid 500); 17 Oct 2013 15:05:46 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 14495 invoked by uid 99); 17 Oct 2013 15:05:46 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Oct 2013 15:05:46 +0000 Date: Thu, 17 Oct 2013 15:05:46 +0000 (UTC) From: "Constance Eustace (JIRA)" To: commits@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (CASSANDRA-6086) Node refuses to start with exception in ColumnFamilyStore.removeUnfinishedCompactionLeftovers when find that some to be removed files are already removed MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CASSANDRA-6086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797976#comment-13797976 ] Constance Eustace edited comment on CASSANDRA-6086 at 10/17/13 3:04 PM: ------------------------------------------------------------------------ Well, how would one repair this for now, beyond reconstructing a virgin node and then replication? If there are counters, certainly you could provide an option for an admin to reset them or accept invalid values and get access to the rest of the data, or mark it in some (tombstone-ish?) way that other nodes with more accurate values for the counters can then replicate the correct state? And yes, we just got this. was (Author: cowardlydragon): Well, how would one repair this for now, beyond reconstructing a virgin node and then replication? If there are counters, certainly you could provide an option for an admin to reset them or accept invalid values and get access to the rest of the data, or mark it in some (tombstone-ish?) way that other nodes with more accurate values for the counters can then replicate the correct state? > Node refuses to start with exception in ColumnFamilyStore.removeUnfinishedCompactionLeftovers when find that some to be removed files are already removed > --------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: CASSANDRA-6086 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6086 > Project: Cassandra > Issue Type: Bug > Components: Core > Reporter: Oleg Anastasyev > Assignee: Oleg Anastasyev > Fix For: 2.0.2 > > Attachments: 6086-v2.txt, removeUnfinishedCompactionLeftovers.txt > > > Node refuses to start with > {code} > Caused by: java.lang.IllegalStateException: Unfinished compactions reference missing sstables. This should never happen since compactions are marked finished before we start removing the old sstables. > at org.apache.cassandra.db.ColumnFamilyStore.removeUnfinishedCompactionLeftovers(ColumnFamilyStore.java:544) > at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:262) > {code} > IMO, there is no reason to refuse to start discivering files that must be removed are already removed. It looks like pure bug diagnostic code and mean nothing to operator (nor he can do anything about this). > Replaced throw of excepion with dump of diagnostic warning and continue startup. -- This message was sent by Atlassian JIRA (v6.1#6144)