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

Hadoop QA commented on HBASE-14309:
-----------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12753130/14309-v7-branch-1.txt
  against branch-1 branch at commit 4256128fa248b31c0482bdfc2510011771f84037.
  ATTACHMENT ID: 12753130

    {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:red}-1 javac{color}.  The patch appears to cause mvn compile goal to 
fail with Hadoop version 2.4.0.

    Compilation errors resume:
    [ERROR] Error invoking method 'get(java.lang.Integer)' in 
java.util.ArrayList at META-INF/LICENSE.vm[line 1619, column 22]
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process (default) on 
project hbase-assembly: Error rendering velocity resource. Error invoking 
method 'get(java.lang.Integer)' in java.util.ArrayList at 
META-INF/LICENSE.vm[line 1619, column 22]: InvocationTargetException: Index: 0, 
Size: 0 -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :hbase-assembly
    

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

This message is automatically generated.

> Allow load balancer to operate when there is region in transition by adding 
> force flag
> --------------------------------------------------------------------------------------
>
>                 Key: HBASE-14309
>                 URL: https://issues.apache.org/jira/browse/HBASE-14309
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Ted Yu
>            Assignee: Ted Yu
>             Fix For: 2.0.0, 1.3.0
>
>         Attachments: 14309-branch-1.1.txt, 14309-v1.txt, 14309-v2.txt, 
> 14309-v3.txt, 14309-v4.txt, 14309-v5-branch-1.txt, 14309-v5.txt, 
> 14309-v5.txt, 14309-v6.txt, 14309-v7-branch-1.txt, 14309-v7.txt
>
>
> This issue adds boolean parameter, force, to 'balancer' command so that admin 
> can force region balancing even when there is region in transition - assuming 
> RIT being transient.
> This enhancement was requested by some customer.
> The assumption of this change is that the operator has run hbck and has a 
> reasonable idea why regions are stuck in transition before using the force 
> flag.
> There was a recent event at the customer where a cluster ended up with a 
> small number of regionservers hosting most of the regions on the cluster (one 
> regionserver had 50% of the roughly 20,000 regions). The balancer couldn't be 
> run due to the small number of regions that were stuck in transition. The 
> admin ended up killing the regionservers so that reassignment would yield a 
> more equitable distribution of the regions.
> On a different cluster, there was a single store file that had corrupt HDFS 
> blocks (the SSDs on the cluster were known to lose data). However, since this 
> single region (out of 10s of 1000s of regions on this cluster) was stuck in 
> transition, the balancer couldn't run.
> While the state keeping in HBase isn't so good yet that the admin can kick 
> off the balancer automatically in such scenarios knowing when it is safe to 
> do so and when it is not, having this option available for the operator to 
> use as he / she sees fit seems prudent.



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

Reply via email to