[
https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14533662#comment-14533662
]
Ariel Weisberg commented on CASSANDRA-9318:
-------------------------------------------
Ah, I get it. So this make sense now and I think it's fixable in the context of
bounding at the coordinator. CL=1 means we have to send the response back to
the client, it doesn't mean we have to release the permit associated with
in-flight writes.
We could come up with a suitable definition of allowed concurrency for requests
that continue to execute even after the response has gone back to the client.
How this compares with other approaches to bounding utilization in terms of
complexity and efficacy is still up for discussion.
> 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.1.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)
