[ 
https://issues.apache.org/jira/browse/HBASE-14263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14717496#comment-14717496
 ] 

Hadoop QA commented on HBASE-14263:
-----------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12751409/HBASE-14263.patch
  against master branch at commit 8f95318f6252c1c0b7a073619525eae6d991f47b.
  ATTACHMENT ID: 12751409

    {color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

    {color:red}-1 tests included{color}.  The patch doesn't appear to include 
any new or modified tests.
                        Please justify why no new tests are needed for this 
patch.
                        Also please list what manual steps were performed to 
verify this patch.

    {color:green}+1 hadoop versions{color}. The patch compiles with all 
supported hadoop versions (2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.7.0)

    {color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

    {color:green}+1 protoc{color}.  The applied patch does not increase the 
total number of protoc compiler warnings.

    {color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

    {color:green}+1 checkstyle{color}.  The applied patch does not increase the 
total number of checkstyle errors

    {color:green}+1 findbugs{color}.  The patch does not introduce any  new 
Findbugs (version 2.0.3) warnings.

    {color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

    {color:green}+1 lineLengths{color}.  The patch does not introduce lines 
longer than 100

  {color:green}+1 site{color}.  The mvn post-site goal succeeds with this patch.

     {color:red}-1 core tests{color}.  The patch failed these unit tests:
                       
org.apache.hadoop.hbase.regionserver.TestDefaultCompactSelection

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/15304//testReport/
Release Findbugs (version 2.0.3)        warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/15304//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors: 
https://builds.apache.org/job/PreCommit-HBASE-Build/15304//artifact/patchprocess/checkstyle-aggregate.html

  Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/15304//console

This message is automatically generated.

> ExploringCompactionPolicy logic around file selection is broken
> ---------------------------------------------------------------
>
>                 Key: HBASE-14263
>                 URL: https://issues.apache.org/jira/browse/HBASE-14263
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Vladimir Rodionov
>            Assignee: Vladimir Rodionov
>             Fix For: 2.0.0
>
>         Attachments: HBASE-14263.patch
>
>
> It seems that logic around selection of store file candidates is broken:
> {code}
>         // Compute the total size of files that will
>         // have to be read if this set of files is compacted.
>         long size = getTotalStoreSize(potentialMatchFiles);
>         // Store the smallest set of files.  This stored set of files will be 
> used
>         // if it looks like the algorithm is stuck.
>         if (mightBeStuck && size < smallestSize) {
>           smallest = potentialMatchFiles;
>           smallestSize = size;
>         }
>         if (size > comConf.getMaxCompactSize()) {
>           continue;
>         }
>         ++opts;
>         if (size >= comConf.getMinCompactSize()
>             && !filesInRatio(potentialMatchFiles, currentRatio)) {
>           continue;
>         }
> {code}
> This is from applyCompactionPolicy method. As you can see, both min 
> compaction size and max compaction size are applied to a *selection* of files 
> and not to individual files. It mostly works as expected only because nobody 
> seems using non-default hbase.hstore.compaction.max.size, which is  
> Long.MAX_VALUE  and  it  is not  that  easy  to  figure out  what  is  going  
> on  on an opposite side (why small files do not get included?)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to