cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dikang Gu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-12248) Allow tuning compaction thread count at runtime
Date Wed, 28 Sep 2016 23:05:20 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-12248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15531153#comment-15531153
] 

Dikang Gu commented on CASSANDRA-12248:
---------------------------------------

[~zznate], I think [~tjake] means something like this: https://github.com/DikangGu/cassandra/commit/eea231de9200a55f14f87dc97ec8acbdaa3f8663.
When we are reducing the number of compactors, we need to set the core pool size first, other
wise, it will throw exception like this:
{code}
Exception in thread "main" java.lang.IllegalArgumentException
	at java.util.concurrent.ThreadPoolExecutor.setMaximumPoolSize(ThreadPoolExecutor.java:1667)
{code}

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

Mime
View raw message