hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10060) Unsynchronized scanning
Date Sun, 01 Dec 2013 03:20:35 GMT

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

Lars Hofhansl commented on HBASE-10060:

So to be specific we use the RegionScannerImpl, which already takes a lock for "normal" scans.
For compactions/flushes we lock the scanner for the entire operation ahead of time. For this
to work we need part of HBASE-9949 in 0.96 and 0.94 (the part where we also call updateReaders
StoreScanner on behalf on compactions and flushes). Then we can use the lock on StoreScanner.updateReader
to delay replacing the readers.
Might be easiest to j

> 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

View raw message