[
https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15489612#comment-15489612
]
Stefania commented on CASSANDRA-9318:
-------------------------------------
bq. Alright, looks like queryStartNanoTime replaced the old start variable in
the latest rebase, let me fix that and check/rerun tests.
I understand now. {{queryStartNanoTime}} was introduced by CASSANDRA-12256, it
comes all the way from {{QueryProcessor}}. I think the aim was to to take into
account the full query processing time from the client point of view, including
CQL parsing and so forth. Should we increase the timeout by the amount of time
spent waiting for the backpressure strategy rather than resetting the start
time? Also, it should not be changed if the backpressure strategy is disabled.
> 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)
