[
https://issues.apache.org/jira/browse/HBASE-14575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14996404#comment-14996404
]
ramkrishna.s.vasudevan edited comment on HBASE-14575 at 11/9/15 12:05 PM:
--------------------------------------------------------------------------
Going thro the code and the patch I think the writeState itself is going to
help us with region close and compactions.
bq.#4 needs region read lock - this requirement is kept in patch.
You mean this step ,
bq.4. swap in compacted files
You want to guard here when there is bulk load in parallel?
Because with region close and compaction I don't think we need to guard them.
May be one thing we can add, after holding the lock
{code}
// Do the steps necessary to complete the compaction. Hold region open for
these operations.
1256 region.lock.readLock().lock();
1257 try {
1258 sfs = moveCompatedFilesIntoPlace(cr, newFiles, user);
1259 writeCompactionWalRecord(filesToCompact,
{code}
check if the closing is true. If so just return. That would solve all the cases
I think, because if compaction is in progress close cannot proceed. IF close
has started then already it would have held the write lock, in that case this
read lock can just return on seeing closing=true.
was (Author: ram_krish):
Going thro the code and the patch I think the writeState itself is going to
help us with region close and compactions.
bq.#4 needs region read lock - this requirement is kept in patch.
You mean this step right?
bq.4. swap in compacted files
This wrt to bulk load you want to hold it right?
Because with region close and compaction I don't think we need to guard them.
May be one thing we can add, after holding the lock
{code}
// Do the steps necessary to complete the compaction. Hold region open for
these operations.
1256 region.lock.readLock().lock();
1257 try {
1258 sfs = moveCompatedFilesIntoPlace(cr, newFiles, user);
1259 writeCompactionWalRecord(filesToCompact,
{code}
check if the closing is true. If so just return. That would solve all the cases
I think, because if compaction is in progress close cannot proceed. IF close
has started then already it would have held the write lock, in that case this
read lock can just return on seeing closing=true.
> Reduce scope of compactions holding region lock
> -----------------------------------------------
>
> Key: HBASE-14575
> URL: https://issues.apache.org/jira/browse/HBASE-14575
> Project: HBase
> Issue Type: Sub-task
> Components: Compaction, regionserver
> Reporter: Nick Dimiduk
> Assignee: Nick Dimiduk
> Attachments: 14575-v1.patch, 14575-v2.patch, 14575-v3.patch,
> 14575-v4.patch, 14575-v5.patch, 14575.v00.patch
>
>
> Per [~devaraj]'s idea on parent issue, let's see if we can reduce the scope
> of critical section under which compactions hold the region read lock.
> Here is summary from parent issue:
> Another idea is we can reduce the scope of when the read lock is held during
> compaction. In theory the compactor only needs a region read lock while
> deciding what files to compact and at the time of committing the compaction.
> We're protected from the case of region close events because compactions are
> checking (every 10k bytes written) if the store has been closed in order to
> abort in such a case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
