[ https://issues.apache.org/jira/browse/CASSANDRA-13055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15765515#comment-15765515 ]
Yuki Morishita commented on CASSANDRA-13055: -------------------------------------------- bq. Another thing is that CASSANDRA-7795 added StreamReceiveTask executor's limited by FBUtilities.getAvailableProcessors(), but this limit was removed by CASSANDRA-6455 without clear reason, so I believe it could be a merge error. I didn't exactly remember, but looking at {{DebuggableThreadPoolExecutor.createWithMaximumPoolSize}} which was used before 6455, it can glow indefinitely with {{maximumPoolSize}} of {{Integer.MAX_VALUE}}. Maybe that was the reason I changed that line. > DoS by StreamReceiveTask, during incremental repair > --------------------------------------------------- > > Key: CASSANDRA-13055 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13055 > Project: Cassandra > Issue Type: Bug > Reporter: Tom van der Woerdt > Attachments: untitled 2.txt > > > There's no limit on how many StreamReceiveTask there can be, and during an > incremental repair on a vnode cluster with high replication factors, this can > lead to thousands of conccurent StreamReceiveTask threads, effectively DoSing > the node. > I just found one of my nodes with 1000+ loadavg, caused by 1363 concurrent > StreamReceiveTask threads. > That sucks :) > I think : > * Cassandra shouldn't allow more than X concurrent StreamReceiveTask threads > * StreamReceiveTask threads should be at a lower priority, like compaction > threads > Alternative ideas welcome as well, of course. -- This message was sent by Atlassian JIRA (v6.3.4#6332)