[
https://issues.apache.org/jira/browse/CASSANDRA-2558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026991#comment-13026991
]
Sylvain Lebresne commented on CASSANDRA-2558:
---------------------------------------------
The thing is, ThreadPoolExecutor throws an IllegalArgumentException if
maxPoolSize is 0. So I do agree that having concurrent_compactors=0 disable
compaction would be "coherent", but is it worth the extra code that will be
needed (I don't see a super easy way to do this right off the bat) ? And after
all disabling compaction is not something we want to encourage.
An alternative would be to simply throw a ConfigurationException if the
provided number is <= 0, if what we want is avoiding silent correction.
> Add "concurrent_compactions" configuration
> ------------------------------------------
>
> Key: CASSANDRA-2558
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2558
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.8 beta 1
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Trivial
> Fix For: 0.8.1
>
> Attachments: 0001-Make-compaction-thread-number-configurable.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> We should expose a way to configure the max number of thread to use when
> multi_threaded compaction is turned on. So far, it uses nb_of_processors
> thread, which if you have many cores may be unreasonably high (as far as
> random IO is concerned and thus independently of compaction throttling)... at
> least unless you have SSD.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
