[
https://issues.apache.org/jira/browse/HBASE-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029528#comment-13029528
]
stack commented on HBASE-3797:
------------------------------
@N
That sounds like some good testing done already. Agree should be good for
TRUNK. Yeah, on commit, lets change default. I'm ok if its sub-optimal on
commit and we tune it later rather than other way around because then folks
will notice that this fancy new stuff exists.
CompactionRequestor.java#34: I'm ok on limiting refactoring.
Would suggest you remove setServer method for SplitRequest.java#34 on commit.
I'm good on the rest. You want to make a new patch or you just want me to
commit this (with amendments above)?
> StoreFile Level Compaction Locking
> ----------------------------------
>
> Key: HBASE-3797
> URL: https://issues.apache.org/jira/browse/HBASE-3797
> Project: HBase
> Issue Type: Improvement
> Reporter: Nicolas Spiegelberg
> Assignee: Nicolas Spiegelberg
> Priority: Minor
> Attachments: HBASE-3797+1476.patch
>
>
> Multithreaded compactions (HBASE-1476) will solve the problem of major
> compactions clogging high-priority minor compactions. However, there is
> still a problem here. Since compactions are store-level, the store
> undergoing major compaction will have it's storefile count increase during
> the major. We really need a way to allow multiple outstanding compactions
> per store. compactSelection() should lock/reserve the files being used for
> compaction. This will also allow us to know what we're going to compact when
> inserting into the CompactSplitThread and make more informed priority
> queueing decisions.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
