Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 9 Jul 2015 17:28:04 +0000 (UTC)
From: "Tyler Hobbs (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12843910.1436462825000.144958.1436462884591@Atlassian.JIRA>
In-Reply-To: <JIRA.12843910.1436462825000@Atlassian.JIRA>
References: <JIRA.12843910.1436462825000@Atlassian.JIRA>
 <JIRA.12843910.1436462825644@arcas>
Subject: [jira] [Created] (CASSANDRA-9772) Bound the number of concurrent
 range requests
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Tyler Hobbs created CASSANDRA-9772:
--------------------------------------

             Summary: Bound the number of concurrent range requests
                 Key: CASSANDRA-9772
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9772
             Project: Cassandra
          Issue Type: Improvement
          Components: Core
            Reporter: Tyler Hobbs
            Assignee: Tyler Hobbs
             Fix For: 2.1.x, 2.2.x


After CASSANDRA-1337, we will execute requests for many token ranges concurrently based on our estimate of how many ranges will be required to meet the requested LIMIT.  For queries with a lot of results this is generally fine, because it will only take a few ranges to satisfy the limit.  However, for queries with very few results, this may result in the coordinator concurrently requesting all token ranges.  On large vnode clusters, this will be particularly problematic.

Placing a simple bound on the number of concurrent requests is a good first step.  Long-term, we should look into creating a new range command that supports requesting multiple ranges.  This would eliminate the overhead of serializing and handling hundreds of separate commands.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)