[
https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15489764#comment-15489764
]
Sylvain Lebresne commented on CASSANDRA-9318:
---------------------------------------------
bq. If we don't do this, then users have to manually increase the timeout when
enabling back-pressure, by an amount of time that is not known a priori.
Why? Again, we want the timeout to mean, in the context of CASSANDRA-12256 and
CASSANDRA-2848, is an upper on the server answering to the application (even if
that means giving up). In other words, the timeout is about what the
application needs, and that shouldn't be influenced by having back-pressure on
or not. Besides, back-pressure should be largely transparent from the user
point of view, at least as long as nothing goes too bad (and it should
hopefully make things better otherwise, not worse), so it makes no sense from
the user point of view to have to bump the timeout just because back-pressure
is enabled.
> 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)
