cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefania (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight requests at the coordinator
Date Wed, 14 Sep 2016 06:46:22 GMT


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:
>             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,
> 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

This message was sent by Atlassian JIRA

View raw message