Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id F242C10A3E for ; Wed, 31 Dec 2014 03:20:14 +0000 (UTC) Received: (qmail 51908 invoked by uid 500); 31 Dec 2014 03:20:13 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 51855 invoked by uid 500); 31 Dec 2014 03:20:13 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 51678 invoked by uid 99); 31 Dec 2014 03:20:13 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 Dec 2014 03:20:13 +0000 Date: Wed, 31 Dec 2014 03:20:13 +0000 (UTC) From: "James Taylor (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (HBASE-12790) Support fairness across parallelized scans MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 James Taylor created HBASE-12790: ------------------------------------ Summary: Support fairness across parallelized scans Key: HBASE-12790 URL: https://issues.apache.org/jira/browse/HBASE-12790 Project: HBase Issue Type: Bug Reporter: James Taylor Some HBase clients parallelize the execution of a scan to reduce latency in getting back results. This can lead to starvation with a loaded cluster and interleaved scans, since the RPC queue will be ordered and processed on a FIFO basis. For example, if there are two clients, A & B that submit largish scans at the same time. Say each scan is broken down into 100 scans by the client (broken down into equal depth chunks along the row key), and the 100 scans of client A are queued first, followed immediately by the 100 scans of client B. In this case, client B will be starved out of getting any results back until the scans for client A complete. One solution to this is to use the attached AbstractRoundRobinQueue instead of the standard FIFO queue. The queue to be used could be (maybe it already is) configurable based on a new config parameter. Using this queue would require the client to have the same identifier for all of the 100 parallel scans that represent a single logical scan from the clients point of view. With this information, the round robin queue would pick off a task from the queue in a round robin fashion (instead of a strictly FIFO manner) to prevent starvation over interleaved parallelized scans. -- This message was sent by Atlassian JIRA (v6.3.4#6332)