[ 
https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15092215#comment-15092215
 ] 

Ariel Weisberg commented on CASSANDRA-9318:
-------------------------------------------

I am not sure how they have structured things and why they need to do that. 
With a hard limit on ingest rate and a 2 second timeout there is a soft bound 
on how much memory can be committed. It's not a hard bound because there is no 
guarantee that the timeout thread will keep up.

I do think that switching requests from async to sync based on load is a better 
approach than enabling/disabling read on client connections. There can be a lot 
of client connections so that is something that can be time consuming.

I am not sold that we should do anything at all? We could add more code to 
address this, but I hate to do that when I can't demonstrate that I am solving 
a problem. I split off what I consider the good bits into CASSANDRA-10971 and 
CASSANDRA-10972. The delay has been other work, me considering this to be 
lowish priority since I can't demonstrate it, and difficulty getting hardware 
going that is capable of demonstrating the problem. I'm slowly iterating on it 
in the background right now.

> Bound the number of in-flight requests at the coordinator
> ---------------------------------------------------------
>
>                 Key: CASSANDRA-9318
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9318
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Local Write-Read Paths, Streaming and Messaging
>            Reporter: Ariel Weisberg
>            Assignee: Ariel Weisberg
>             Fix For: 2.1.x, 2.2.x
>
>
> It's possible to somewhat bound the amount of load accepted into the cluster 
> by bounding the number of in-flight requests and request bytes.
> An implementation might do something like track the number of outstanding 
> bytes and requests and if it reaches a high watermark disable read on client 
> connections until it goes back below some low watermark.
> Need to make sure that disabling read on the client connection won't 
> introduce other issues.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to