You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2016/02/08 11:59:39 UTC
[jira] [Commented] (CASSANDRA-11082) netty's level hadn't prevent
OOM when receiver handle slow.
[ https://issues.apache.org/jira/browse/CASSANDRA-11082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136805#comment-15136805 ]
Sylvain Lebresne commented on CASSANDRA-11082:
----------------------------------------------
So you're saying that we don't have any back-pressure mechanism regarding client being too slow at receiving responses (and hence data to send accumulating server side)? Am I understanding that correctly?
If so, I suppose that's true or at least I'm not aware of us doing anything special to prevent that. And it's a good question as to why we configure the high/low watermark given that we never check {{Channel.isWritable()}}: [~tjake], you introduced those configuration on CASSANDRA-6861?
With that said, there isn't too much evidence so far that OOM due to clients being too slow to receive their responses is very common so lowering the priority.
> netty's level hadn't prevent OOM when receiver handle slow.
> -----------------------------------------------------------
>
> Key: CASSANDRA-11082
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11082
> Project: Cassandra
> Issue Type: Bug
> Components: Streaming and Messaging
> Reporter: fujian
> Priority: Critical
>
> as we know, netty will OOM when received client is slow.
> due to if receiver can't handle response fast so that cassandra server can't flush data. it will cause channeloutbuffer with big size.
> we see the cassandra had configure write high/low water level, but I can't found any code to judge iswritable. so it will have possible OOM
> why cassandra hadn't handle this case?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)