[
https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15375191#comment-15375191
]
Sergio Bossa commented on CASSANDRA-9318:
-----------------------------------------
[~slebresne],
bq. if we make the strategy a bit more generic as mentioned above so the
decision is made from all replica involved (maybe the strategy should also keep
track of the replica-state completely internally so we can implement basic
strategy like having a simple high watermark very easy)
I'm already separating the "computation" phase from the "application", in order
to address some previous points from my discussion with [~Stefania], so I think
that should do it.
bq. and we make sure to not throttle too quickly (typically, if a single
replica is slow and we don't really need it, start by just hinting him)
This can be easily implemented in the strategy itself as a parameter, i.e.
"back-pressure cycles before actually starting to rate limit", so I'll do this
eventually later.
> 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)
