[
https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15389176#comment-15389176
]
Sergio Bossa commented on CASSANDRA-9318:
-----------------------------------------
[~Stefania],
bq. OK, so we are basically saying other coordinator-based approaches won't be
implemented as a back-pressure strategy.
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.
bq. There's another overload of sendRR
I ignored it on purpose as that's supposed to be for non mutations.
bq. One final thought, now we have N rate limiters, and we call aquire(1) on
only one of them. For the next mutation we may pick another one and so forth.
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?
> 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)
