[
https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14604715#comment-14604715
]
Benedict commented on CASSANDRA-9318:
-------------------------------------
bq. shedding is strictly worse
If we can do so without affecting our availability guarantees, sure.
bq. the contract
We already drop hints on the floor if they cannot keep up.
To be clear: all I'm effectively suggesting is we "hint" (including the hinting
step that drops hints\*) earlier. This in no way affects our contract or
guarantees, since we don't do anything at all in the intervening period except
consume memory. All we do is wait until the timeout expires and then hint. This
simply preempts the timer and hints immediately, possibly resulting in the
message being delivered via hints when it was delivered successfully (but very
late) first time around, but also possibly resulting in the hint being dropped,
as it could be at either time.
\* except that we can probably make this decision _less_ pessimistic than it is
currently, with better visibility on overall resource utilisation.
> 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)
