[
https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379014#comment-15379014
]
Sergio Bossa commented on CASSANDRA-9318:
-----------------------------------------
Based on everyone's feedback above, I propose to move forward with these
changes:
* Break the {{BackPressureStrategy}} apply method into two, one to compute the
back-pressure state and return it sorted in ascending order (from lower
back-pressure to higher/overloader), the other to actually apply it.
* Apply back-pressure on all nodes/states together, and have
{{RateBasedBackPressure}} apply it based on the faster, slower, or average
rate, depending on configuration: this is to "soften" [~jbellis]' concern about
always limiting at the slowest rate.
* Rework {{SP.sendToHintedEndpoints}} a little bit to send mutations in the
order returned by the {{BackPressureStrategy}}: this is a minor optimization
based on the reasoning that "slower replicas" might be also slower to accept
writes at the TCP level, and I can skip it if people prefer not to touch SP too
much.
* Also have {{SP.sendToHintedEndpoints}} directly hint overloaded replicas
rather than back-pressure them or throw exception; again, this is an
optimization to avoid wasting time with dealing with too slow replicas.
Regarding the memory-threshold strategy, I'll hold on implementing it until we
consolidate the points above.
Regarding any changes related to the write request path going fully
non-blocking, code placement will probably change but all such core concepts
will stay the same, and I'll be happy to work on any changes needed
(CASSANDRA-8457 is another one to keep an eye on /cc [~jasobrown]).
> 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)
