Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 3 Oct 2013 16:50:42 +0000 (UTC)
From: "lantao yan (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12624614.1355918313249.7815.1380819042569@arcas>
In-Reply-To: <JIRA.12624614.1355918313249@arcas>
References: <JIRA.12624614.1355918313249@arcas>
Subject: [jira] [Commented] (CASSANDRA-5078) save compaction merge counts in
 a system table
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

lantao yan commented on CASSANDRA-5078:
---------------------------------------

[~yukim], [~jbellis], I checked that code, although two threads can work one the same column family. but in case of one thread is compacting, another thread would fail? I was worrying if two threads compacting the same set of files, we could have risk condition? given that, this problem is not actually changing the primary key.

ColumnFamilyStore.java
                assert data.getCompacting().isEmpty() : data.getCompacting();

correct me if I am wrong. I will keep reading the code. thanks.

> save compaction merge counts in a system table
> ----------------------------------------------
>
>                 Key: CASSANDRA-5078
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5078
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Matthew F. Dennis
>            Assignee: lantao yan
>            Priority: Minor
>              Labels: lhf
>         Attachments: 5078-v3.txt, 5078-v4.txt, patch1.patch
>
>
> we should save the compaction merge stats from CASSANDRA-4894 in the system table and probably expose them via JMX (and nodetool)


--
This message was sent by Atlassian JIRA
(v6.1#6144)