hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-3797) StoreFile Level Compaction Locking
Date Thu, 05 May 2011 19:39:03 GMT

    [ 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:


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

View raw message