[
https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15397353#comment-15397353
]
Sergio Bossa commented on CASSANDRA-9318:
-----------------------------------------
[~Stefania],
bq. HintsDispatcher.Callback goes through the other one. Also, it is not
consistent with the fact that supportsBackPressure() is defined at the callback
level.
Fair enough, {{supportsBackPressure()}} will do its job in excluding spurious
calls anyway.
bq. But the time windows of replicas do not necessarily match, they might be
staggered.
The algorithm was meant to work at steady state, assuming even key
distribution, but you made me realize it was nonetheless exposed to subtle
fluctuations, so thanks for the excellent point :)
It should be now fixed in the latest round of commits.
I'm pretty happy with this latest version, so if you're happy too, I'll move
forward with a last self-review round and then rebase into trunk.
> 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)
