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

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

It definitely does almost nothing for large reads. For writes it might work OK 
if everything is distributed evenly.

Do you think it doesn't help for writes either? Even if the coordinator doesn't 
know about how much load each remote participant has in aggregate if load is 
even it does place a bound. What does happen that is unfortunate is that over 
time all requests end up being for the slowest node given enough time which can 
bring it down and prevent progress at other nodes.

I agree that other approaches that can shed load where it actually happens 
based on actual load metrics and not admission control guesses will be more 
effective in the long run.



> 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
>            Reporter: Ariel Weisberg
>            Assignee: Ariel Weisberg
>             Fix For: 3.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