Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Sun, 28 Jun 2015 16:31:06 +0000 (UTC)
From: "Aleksey Yeschenko (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12827721.1430931031000.38620.1435509066104@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


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

Aleksey Yeschenko commented on CASSANDRA-9318:
----------------------------------------------

bq. On flushing hints, we can ignore any that have been delivered (which we would prefer to do anyway). We ideally only flush the hints buffer after the timeout interval has elapsed, or alternatively if we run out of a generous memory allowance.

This we can/should do.

bq. With some small tweaks we would only need to keep a minimal piece of identifying information to invalidate the hint record, even after it has been written to disk.

I would prefer not go after records that already made it to disk - the former should be good enough.

In general, let's keep hints chatter to CASSANDRA-6230 ticket comments, please.

As for the matter at hands - we should bound both write and read queues, but certainly not just by some fixed queue lengths. For reads we should be bound by a fixed size read buffer on one side, and SLA on the other side - that we could do once we have the ability to terminate the queries in flight. For writes, don't have an opinion formed, yet.

> 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
>            Reporter: Ariel Weisberg
>            Assignee: Ariel Weisberg
>             Fix For: 2.1.x, 2.2.x
>
>
> 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)