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)