Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 13 Jul 2016 13:45:21 +0000 (UTC)
From: "Jonathan Ellis (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12827721.1430931031000.16146.1468417521186@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: Wed, 13 Jul 2016 13:45:23 -0000


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

Jonathan Ellis commented on CASSANDRA-9318:
-------------------------------------------

bq. Hints are not a solution for chronically overloaded clusters where clients ingest faster than replicas can consume

That is the situation I describe in scenario 3, which is the problem I opened this ticket to solve.  So, I agree that scenario is a problem, but I don't think this proposal is a very good solution for that, and it causes other problems in the other two (non-global-overload) scenarios.

bq. I think we do solve that, actually in a better way, which takes into consideration all replicas, not just the coordinator capacity of acting as a buffer, unless I'm missing a specific case you're referring to?

I honestly don't see what is "better" about a "slow every write down to the speed of the slowest, possibly sick, replica" approach.  Defining a simple high water mark on requests in flight should be much simpler without the negative side effects.

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