You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2018/03/02 01:33:00 UTC
[jira] [Resolved] (HBASE-13530) Add param for bulkload wait
duration in HRegion.
[ https://issues.apache.org/jira/browse/HBASE-13530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack resolved HBASE-13530.
---------------------------
Resolution: Duplicate
Reporter says HBASE-14575 fixes their issue. Resolving.
> Add param for bulkload wait duration in HRegion.
> ------------------------------------------------
>
> Key: HBASE-13530
> URL: https://issues.apache.org/jira/browse/HBASE-13530
> Project: HBase
> Issue Type: Improvement
> Components: regionserver
> Affects Versions: 0.98.12
> Reporter: Victor Xu
> Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-13530-0.98-v2.patch, HBASE-13530-0.98.patch, HBASE-13530-master-v2.patch, HBASE-13530-master.patch, HBASE-13530-v1.patch
>
>
> In our scenario, incremental read/write operations and complete bulkload operations are mixed together. Bulkload needs write lock while read/write and flush/compact need read lock. When a region is compacting, the bulkload could hang at writeLock.tryLock(waitDuration, TimeUnit) method. The original default waitDuration is 60sec (from 'hbase.busy.wait.duration'), and this could block all read/writes operations from acquiring read lock for 1 minute. The chances of this scenario become high when compaction speed limit feature(HBASE-8329) is used.
> Maybe we need to decrease the wait duration ONLY for bulkload, and let read/write keep theirs. So I add this param('hbase.bulkload.wait.duration') to tune wait duration for bulkloading. Of course, it is a table level setting, and the default value is from original logic.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)