Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 22 Jul 2016 09:56:21 +0000 (UTC)
From: "Stefania (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12827721.1430931031000.105714.1469181381038@Atlassian.JIRA>
In-Reply-To: <JIRA.12827721.1430931031000@Atlassian.JIRA>
References: <JIRA.12827721.1430931031000@Atlassian.JIRA> <JIRA.12827721.1430931031849@arcas>
Subject: [jira] [Commented] (CASSANDRA-9318) Bound the number of in-flight
 requests at the coordinator
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 22 Jul 2016 09:56:23 -0000


    [ https://issues.apache.org/jira/browse/CASSANDRA-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15389246#comment-15389246 ] 

Stefania commented on CASSANDRA-9318:
-------------------------------------

bq. 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.

Except the state may have nothing to do with a replica but let's leave it for now, I'm fine with this.

bq. I ignored it on purpose as that's supposed to be for non mutations.

HintsDispatcher.Callback goes through the other one. Also, it is not consistent with the fact that supportsBackPressure() is defined at the callback level.

bq. 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?

But the time windows of replicas do not necessarily match, they might be staggered. For example replicas 1, 2 and 3 acquired a window for mutation A at the same time, then replicas 2, 3, 4 are used for mutation B, in this case only 3 and 4 will acquire the window because 2 acquired it earlier, so the order may change even during a window. Or does it work by approximation, assuming we send mutations to all replicas frequently enough?


> 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)