[
https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15378784#comment-15378784
]
Stefania commented on CASSANDRA-9318:
-------------------------------------
I don't have much to add regarding the merits of one approach vs. the other,
other than to say that I agree with [~slebresne] that we should implement the
strategy API so that both strategies can be supported, and this will make it
more likely that the API is fit for even more strategies. I would even go one
step further and suggest that the second strategy should be relatively easy to
implement if the framework is in place and if we can work out a reasonable
threshold. Therefore we could consider implementing and testing both, either as
part of a follow up ticket or this one.
Another thing I would like to point out is that, once we make read and write
requests fully non-blocking, either via CASSANDRA-10993 or CASSANDRA-10528, we
will probably have to rethink this.
> 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
> Components: Local Write-Read Paths, Streaming and Messaging
> Reporter: Ariel Weisberg
> Assignee: Sergio Bossa
> Attachments: 9318-3.0-nits-trailing-spaces.patch, backpressure.png,
> limit.btm, no_backpressure.png
>
>
> 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)
