[
https://issues.apache.org/jira/browse/HBASE-11368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14983879#comment-14983879
]
ramkrishna.s.vasudevan commented on HBASE-11368:
------------------------------------------------
This comment
https://issues.apache.org/jira/browse/HBASE-11368?focusedCommentId=14693166&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14693166
is getting addressed as part of HBASE-13082. So doing that JIRA would mean
that any current on going scan will not be able to see the bulk loaded hfiles
which is loaded just after the current scan has started. I think that behaviour
should be acceptable, right?
> Multi-column family BulkLoad fails if compactions go on too long
> ----------------------------------------------------------------
>
> Key: HBASE-11368
> URL: https://issues.apache.org/jira/browse/HBASE-11368
> Project: HBase
> Issue Type: Bug
> Reporter: stack
> Assignee: Qiang Tian
> Attachments: hbase-11368-0.98.5.patch, hbase11368-master.patch,
> key_stacktrace_hbase10882.TXT, performance_improvement_verification_98.5.patch
>
>
> Compactions take a read lock. If a multi-column family region, before bulk
> loading, we want to take a write lock on the region. If the compaction takes
> too long, the bulk load fails.
> Various recipes include:
> + Making smaller regions (lame)
> + [~victorunique] suggests major compacting just before bulk loading over in
> HBASE-10882 as a work around.
> Does the compaction need a read lock for that long? Does the bulk load need
> a full write lock when multiple column families? Can we fail more gracefully
> at least?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
