You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Aleksey Yeschenko (JIRA)" <ji...@apache.org> on 2016/03/18 15:28:33 UTC
[jira] [Resolved] (CASSANDRA-5039) Make sure all instances of
BlockingQueue have configurable and sane limits
[ https://issues.apache.org/jira/browse/CASSANDRA-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aleksey Yeschenko resolved CASSANDRA-5039.
------------------------------------------
Resolution: Won't Fix
> Make sure all instances of BlockingQueue have configurable and sane limits
> --------------------------------------------------------------------------
>
> Key: CASSANDRA-5039
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5039
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.1.7
> Reporter: Oleg Kibirev
> Priority: Minor
> Labels: performance
>
> Currently, most BlockingQueues in cassandra are creating without any limits (execution stages) or with limits high enough to consume gigabytes of heap (PeriodicCommitLogExecutorService). I have observed many cases where a single unresponsive node can bring down entire cluster because others accumulate huge backlogs of operations.
> We need to make sure each queue is configurable through a yaml entry or a system property and defaults are chosen so that any given queue doesn't consume more than 100M of heap. I have successfully tested that adding these limits makes cluster resistant to heavy load or a bad node.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)