[
https://issues.apache.org/jira/browse/CASSANDRA-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13103950#comment-13103950
]
Brandon Williams commented on CASSANDRA-3181:
---------------------------------------------
bq. repair should be on its own executor now, so it shouldn't block minors.
Ok, then maybe I just hit one of the OOM bugs, and compaction had never fully
completed. After restarting I never did any more writes, and we know
compaction won't happen at startup.
bq. If that's the case, then is there really much we want to do ? And even if
we want, we should move that to 1.0.1. Just want to make sure this doesn't hide
a real, unknown, problem.
I think CASSANDRA-2444 was wrong. It should be an option, and one that is off
by default. Starting a server with 1k sstables and having nothing happen is a
bit of a shock, and having no way out of it besides hacks like forcing a flush
or a major isn't great.
> Compaction fails to occur
> -------------------------
>
> Key: CASSANDRA-3181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3181
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.0
> Reporter: Brandon Williams
> Assignee: Benjamin Coverston
> Fix For: 1.0.0
>
>
> Compaction just stops running at some point. To repro, insert like 20M rows
> with a 1G heap and you'll get around 1k sstables. Restarting doesn't help,
> you have to invoke a major to get anything to happen.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
