[
https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14604656#comment-14604656
]
Benedict commented on CASSANDRA-9318:
-------------------------------------
bq. If MS's load is caused by a single replica falling over or unable to keep
up, this is still the right thing to do... or we will exhaust the heap and fall
over.
How does load shedding (or immediately hinting) not prevent this scenario? The
proposal you're making appreciably harms our availability guarantees. Load
shedding and/or hinting does not, and it fulfils this most important criterion.
If we pause accepting requests _from a single client_ once that client is using
in excess of a lower watermark (based on some fair share of available memory in
the MS), and _only that client_ is affected, I think that is an acceptably
constrained loss of availability. Enforcing it globally seems to me to far too
significantly harm our most central USP.
> 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: 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)
