Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sun, 1 Dec 2013 02:19:35 +0000 (UTC)
From: "stack (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12681977.1385859453496.50226.1385864375382@arcas>
In-Reply-To: <JIRA.12681977.1385859453496@arcas>
References: <JIRA.12681977.1385859453496@arcas>
Subject: [jira] [Commented] (HBASE-10060) Unsynchronized scanning
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

stack commented on HBASE-10060:
-------------------------------

bq. During a compaction or flush we'd lock the StoreScanner object for the duration of the compaction/flush

Trying to understand.  No forward progress on scan during a flush or compaction? We'd have to find all outstanding storescanners and lock them all?  THanks.

> Unsynchronized scanning
> -----------------------
>
>                 Key: HBASE-10060
>                 URL: https://issues.apache.org/jira/browse/HBASE-10060
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Lars Hofhansl
>
> HBASE-10015 has some lengthy discussion. The solution there ended up replacing synchronized with ReentrantLock, which - somewhat surprisingly - yielded a non-trivial improvement for tall tables.
> The goal should be to avoid locking in StoreScanner at all. StoreScanner is only accessed by a single thread *except* when we have a concurrent flush or a compaction, which is rare (we'd acquire and release the lock millions of times per second, and compact/flush a few time an hour at the most).


--
This message was sent by Atlassian JIRA
(v6.1#6144)