hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14201) hbck should not take a lock unless fixing errors
Date Tue, 11 Aug 2015 22:16:46 GMT

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

Hadoop QA commented on HBASE-14201:
-----------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12749656/HBASE-14201-v0.patch
  against master branch at commit 6da75355380096b897abab3baa9e0a962044d767.
  ATTACHMENT ID: 12749656

    {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:red}-1 checkstyle{color}.  The applied patch generated 1860 checkstyle
errors (more than the master's current 1858 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:red}-1 lineLengths{color}.  The patch introduces the following lines longer than
100:
    +        LOG.error("Another instance of hbck is fixing HBase, exiting this instance. [If
you are sure" +
+      // Only restore the balancer if it was true when we started repairing and we actually
disabled it.

  {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.util.TestHBaseFsck

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

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

This message is automatically generated.

> hbck should not take a lock unless fixing errors
> ------------------------------------------------
>
>                 Key: HBASE-14201
>                 URL: https://issues.apache.org/jira/browse/HBASE-14201
>             Project: HBase
>          Issue Type: Bug
>          Components: hbck, util
>    Affects Versions: 2.0.0, 1.3.0
>            Reporter: Simon Law
>            Assignee: Simon Law
>             Fix For: 2.0.0, 1.3.0
>
>         Attachments: HBASE-14201-v0.patch
>
>
> By default, hbck is run in a read-only checker mode. In this case, it is
> sensible to let others run. By default, the balancer is left alone,
> which may cause spurious errors, but cannot leave the balancer in a bad
> state. It is dangerous to leave the balancer by accident, so it is only
> ever enabled after fixing, it will never be forced off because of
> racing.
> When hbck is run in fixer mode, it must take an exclusive lock and
> disable the balancer, or all havoc will break loose.
> If you want to stop hbck from running in parallel, the -exclusive flag
> will create the lock file. If you want to force -disableBalancer, that
> option is available too. This makes more semantic sense than -noLock and
> -noSwitchBalancer, respectively.
> This task is related to HBASE-14092.



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

Mime
View raw message