Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 20 Oct 2015 05:42:28 +0000 (UTC)
From: "ramkrishna.s.vasudevan (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12776620.1424500574000.4683.1445319748129@Atlassian.JIRA>
In-Reply-To: <JIRA.12776620.1424500574000@Atlassian.JIRA>
References: <JIRA.12776620.1424500574000@Atlassian.JIRA>
 <JIRA.12776620.1424500574747@arcas>
Subject: [jira] [Commented] (HBASE-13082) Coarsen StoreScanner locks to
 RegionScanner
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

ramkrishna.s.vasudevan commented on HBASE-13082:
------------------------------------------------

bq.I mean maybe we could have a fast path without locking for normal reading since for most scan operation there is no flush involved.
I thought on this but not sure run time if we can decide this. But may be if we can say that use my scan only on files then this feature can easily be used. Already we have something like InternalScan#checkOnlyStoreFiles(). So that can be an indicator. But need to see how the client can specify this. So we can have two types of StoreScanner one which is lock free and other one with lock. Ideally only for the flush case we need this lock behaviour whereas the compactions and bulkload can still go with the versioned approach. 

> Coarsen StoreScanner locks to RegionScanner
> -------------------------------------------
>
>                 Key: HBASE-13082
>                 URL: https://issues.apache.org/jira/browse/HBASE-13082
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Lars Hofhansl
>            Assignee: ramkrishna.s.vasudevan
>         Attachments: 13082-test.txt, 13082-v2.txt, 13082-v3.txt, 13082-v4.txt, 13082.txt, 13082.txt, HBASE-13082.pdf, HBASE-13082_1_WIP.patch, HBASE-13082_2_WIP.patch, HBASE-13082_3.patch, HBASE-13082_4.patch, gc.png, gc.png, gc.png, hits.png, next.png, next.png
>
>
> Continuing where HBASE-10015 left of.
> We can avoid locking (and memory fencing) inside StoreScanner by deferring to the lock already held by the RegionScanner.
> In tests this shows quite a scan improvement and reduced CPU (the fences make the cores wait for memory fetches).
> There are some drawbacks too:
> * All calls to RegionScanner need to be remain synchronized
> * Implementors of coprocessors need to be diligent in following the locking contract. For example Phoenix does not lock RegionScanner.nextRaw() and required in the documentation (not picking on Phoenix, this one is my fault as I told them it's OK)
> * possible starving of flushes and compaction with heavy read load. RegionScanner operations would keep getting the locks and the flushes/compactions would not be able finalize the set of files.
> I'll have a patch soon.


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