[
https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14604662#comment-14604662
]
Benedict commented on CASSANDRA-9318:
-------------------------------------
I'm pretty sure I've made clear a few times that I'm proposing load shedding
based on _both_ resource consumption and timeout. i.e. if we are running out of
resources, we hint, if we completely run out of resources, we shed.
In this case, shedding is _never_ incapable of keeping us in a happy place, and
ensures we absolutely prevent any spam bringing down the server.
I think we need to really separate the two concerns, as we seem to be jumping
between them: keeping the server alive is best done through shedding; helping
users with bulk loaders is best served by pausing single clients that are
exceeding our rate of consumption.
> 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)
