[ https://issues.apache.org/jira/browse/CASSANDRA-12248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15526778#comment-15526778 ]
Dikang Gu commented on CASSANDRA-12248: --------------------------------------- [~tjake], I thought about it before, and I checked the code in `ThreadPoolExecutor.java`, the only check there is {code} public void setMaximumPoolSize(int maximumPoolSize) { if (maximumPoolSize <= 0 || maximumPoolSize < corePoolSize) throw new IllegalArgumentException(); {code} It does not allow set maximumPoolSize less than corePoolSize, which will never happen in my path. But anyway, I will do more testing see if it's really a problem. Thanks! > Allow tuning compaction thread count at runtime > ----------------------------------------------- > > Key: CASSANDRA-12248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12248 > Project: Cassandra > Issue Type: Improvement > Reporter: Tom van der Woerdt > Assignee: Dikang Gu > Priority: Minor > Fix For: 3.10 > > > While bootstrapping new nodes it can take a significant amount of time to > catch up on compaction or 2i builds. In these cases it would be convenient to > have a nodetool command that allows changing the number of concurrent > compaction jobs to the amount of cores on the machine. > Alternatively, an even better variant of this would be to have a setting > "bootstrap_max_concurrent_compactors" which overrides the normal setting > during bootstrap only. Saves me from having to write a script that does it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)