Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 11 Nov 2011 20:02:51 +0000 (UTC)
From: "Sylvain Lebresne (Resolved) (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: 
 <1744504435.21997.1321041771581.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1305312266.21795.1321038291706.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Resolved] (CASSANDRA-3484) Bizarre Compaction Manager
 Behaviour
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sylvain Lebresne resolved CASSANDRA-3484.
-----------------------------------------

       Resolution: Fixed
    Fix Version/s: 1.0.3
         Reviewer: slebresne

Alright, +1 on the patch here, committed.
                
> Bizarre Compaction Manager Behaviour
> ------------------------------------
>
>                 Key: CASSANDRA-3484
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3484
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.2
>         Environment: RHEL 6
> java version "1.6.0_26"
> 6 node cluster (5 nodes 0.8.6, 1 node 1.0.2 minus CASSANDRA-2503)
>            Reporter: Dan Hendry
>             Fix For: 1.0.3
>
>         Attachments: 3484.txt, compaction.png
>
>
> It seems the CompactionManager has gotten itself into a bad state. My 1.0.2 node has been up for 20 hours now - checking via JMX, the compaction manager is reporting that it has completed 14,797,412,000 tasks. Yep, thats right 14 billion tasks and increasing at a rate of roughly 208,400/second. 
> I should point out that I am currently running a major compaction on the node. My theory is that this problem was introduced by CASSANDRA-3363. It looks like SizeTieredCompactionStrategy.getBackgroundTasks() returns a set of task without consideration for any in-progress compactions. Compactions are only kicked off if task.markSSTablesForCompaction() returns true (CompactionManager line 127) but the task resubmission is based only on the task list not being empty (CompactionManager line 141). Should the logic not be to only reschedule if a task has actually been executed?
> I am just waiting now for the major compaction to finish to see if the problem goes away as would be suggested by my theory.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira