[
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)
