[
https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15389246#comment-15389246
]
Stefania commented on CASSANDRA-9318:
-------------------------------------
bq. Nope, you can actually implement such kind of strategy after my latest
changes to the state interface: you just have to keep recording per-replica
state, and then eventually compute a global coordinator state at back-pressure
application.
Except the state may have nothing to do with a replica but let's leave it for
now, I'm fine with this.
bq. I ignored it on purpose as that's supposed to be for non mutations.
HintsDispatcher.Callback goes through the other one. Also, it is not consistent
with the fact that supportsBackPressure() is defined at the callback level.
bq. This can't actually happen. Given the same replica group (token range), the
replicas are sorted in stable rate limiting order, which means the same
fast/slow replica will be picked each time for a given back-pressure window;
obviously, the replica order might change at the next window, but that's by
design and then all mutations will converge again to the same replica: makes
sense?
But the time windows of replicas do not necessarily match, they might be
staggered. For example replicas 1, 2 and 3 acquired a window for mutation A at
the same time, then replicas 2, 3, 4 are used for mutation B, in this case only
3 and 4 will acquire the window because 2 acquired it earlier, so the order may
change even during a window. Or does it work by approximation, assuming we send
mutations to all replicas frequently enough?
> 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)
