[
https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14604659#comment-14604659
]
Jonathan Ellis commented on CASSANDRA-9318:
-------------------------------------------
bq. How does load shedding (or immediately hinting) not prevent this scenario?
I explained that:
bq. if clients are sending more requests to a single replica than we can shed
(rate * timeout > capacity)
Suppose we can hold 1GB of messages before we start having GC trouble, and the
timeout is default 2s. If we get more than 500MB/s of requests for a dead
client we will be in trouble since they are arriving faster than they are shed.
bq. The proposal you're making appreciably harms our availability guarantees.
It does not, because we only throttle when shedding is insufficient to keep us
in a happy place.
bq. If we pause accepting requests from a single client
Then we don't solve the larger problem which is multiple clients teaming up to
overwhelm a coordinator.
> 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)
