[
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)
