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)