[ 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)