[ https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14971157#comment-14971157 ]
Jonathan Ellis commented on CASSANDRA-9318: ------------------------------------------- bq. I'd like to resurrect this one and if time permits take it by following Jonathan's proposal above, except I'd also like to propose an additional form of back-pressure at the coordinator->replica level. The whole point of this ticket is to avoid the complexity of intra-node backpressure, and instead basing coordinator -> client backpressure on the coordinator's local knowledge. (Which is not a perfect view of cluster state but it is a reasonable approximation, especially since it can use its MessagingService state to guess replica problems, even without explicit replica backpressure.) We can always add explicit intra-node backpressure later, they are complementary. But I'm not sure it will be necessary and I want to avoid over-engineering the problem to start. > 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: Jacek Lewandowski > Fix For: 2.1.x, 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)