HBase
  1. HBase
  2. HBASE-9773

Master aborted when hbck asked the master to assign a region that was already online

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.98.0, 0.96.1
    • Component/s: None
    • Labels:
      None
    • Hadoop Flags:
      Reviewed

      Description

      Came across this situation (with a version of 0.96 very close to RC5 version created on 10/11):

      The sequence of events that happened:

      1. The hbck tool couldn't communicate with the RegionServer hosting namespace region due to some security exceptions. hbck INCORRECTLY assumed the region was not deployed.
      In output.log (client side):

      2013-10-12 10:42:57,067|beaver.machine|INFO|ERROR: Region { meta => hbase:namespace,,1381564449706.a0ac0825ba2d0830614e7f808f31787a., hdfs => hdfs://gs-hdp2-secure-1381559462-hbase-12.cs1cloud.internal:8020/apps/hbase/data/data/hbase/namespace/a0ac0825ba2d0830614e7f808f31787a, deployed =>  } not deployed on any region server.
      2013-10-12 10:42:57,067|beaver.machine|INFO|Trying to fix unassigned region...
      

      2. This led to the hbck tool trying to tell the master to "assign" the region.
      In master log (hbase-hbase-master-gs-hdp2-secure-1381559462-hbase-12.log):

      2013-10-12 10:52:35,960 INFO  [RpcServer.handler=4,port=60000] master.HMaster: Client=hbase//172.18.145.105 assign hbase:namespace,,1381564449706.a0ac0825ba2d0830614e7f808f31787a.
      

      3. The master went through the steps - sent a CLOSE to the RegionServer hosting namespace region.
      From master log:

      2013-10-12 10:52:35,981 DEBUG [RpcServer.handler=4,port=60000] master.AssignmentManager: Sent CLOSE to gs-hdp2-secure-1381559462-hbase-1.cs1cloud.internal,60020,1381564439794 for region hbase:namespace,,1381564449706.a0ac0825ba2d0830614e7f808f31787a.
      

      4. The master then tried to assign the namespace region to a region server, and in the process ABORTED:
      From master log:

      2013-10-12 10:52:36,025 DEBUG [RpcServer.handler=4,port=60000] master.AssignmentManager: No previous transition plan found (or ignoring an existing plan) for hbase:namespace,,1381564449706.a0ac0825ba2d0830614e7f808f31787a.; generated random plan=hri=hbase:namespace,,1381564449706.a0ac0825ba2d0830614e7f808f31787a., src=, dest=gs-hdp2-secure-1381559462-hbase-9.cs1cloud.internal,60020,1381564439807; 4 (online=4, available=4) available servers, forceNewPlan=true
      2013-10-12 10:52:36,026 FATAL [RpcServer.handler=4,port=60000] master.HMaster: Master server abort: loaded coprocessors are: [org.apache.hadoop.hbase.security.access.AccessController]
      2013-10-12 10:52:36,027 FATAL [RpcServer.handler=4,port=60000] master.HMaster: Unexpected state : {a0ac0825ba2d0830614e7f808f31787a state=OPEN, ts=1381564451344, server=gs-hdp2-secure-1381559462-hbase-1.cs1cloud.internal,60020,1381564439794} .. Cannot transit it to OFFLINE.
      java.lang.IllegalStateException: Unexpected state : {a0ac0825ba2d0830614e7f808f31787a state=OPEN, ts=1381564451344, server=gs-hdp2-secure-1381559462-hbase-1.cs1cloud.internal,60020,1381564439794} .. Cannot transit it to OFFLINE.
      
      AssignmentManager.assign(HRegionInfo region, boolean setOfflineInZK, boolean forceNewPlan)

      is the method that does all the above. This was called from the HMaster with true for both the boolean arguments.

      1. trunk-9773.patch
        4 kB
        Jimmy Xiang
      2. trunk-9773.addendum
        2 kB
        Jimmy Xiang
      3. trunk-9773_v2.patch
        2 kB
        Jimmy Xiang

        Issue Links

          Activity

          Hide
          stack added a comment -

          Released in 0.96.1. Issue closed.

          Show
          stack added a comment - Released in 0.96.1. Issue closed.
          Hide
          Jimmy Xiang added a comment -

          Jeffrey Zhong, I posted a patch on HBASE-9793. Could you please take a look? Thanks.

          Show
          Jimmy Xiang added a comment - Jeffrey Zhong , I posted a patch on HBASE-9793 . Could you please take a look? Thanks.
          Hide
          Jeffrey Zhong added a comment -

          I will enhance the addendum a little to have a timeout, just like in the assign case. I think we should not use runnable because the open will be retried usually. If the unassign is timed out, the pool won't be blocked.

          Since TimeoutMonitor is disable by default so the open won't retried. While for this JIRA issue, if we timeout unassign is a reasonable solution because in SSH case the host server is dead already so unassign will bail out quick without timeout. For other situations, we give up assignment is acceptable because region assignment is more like a hint to the system and master doesn't have to assign a region by user requests.

          Show
          Jeffrey Zhong added a comment - I will enhance the addendum a little to have a timeout, just like in the assign case. I think we should not use runnable because the open will be retried usually. If the unassign is timed out, the pool won't be blocked. Since TimeoutMonitor is disable by default so the open won't retried. While for this JIRA issue, if we timeout unassign is a reasonable solution because in SSH case the host server is dead already so unassign will bail out quick without timeout. For other situations, we give up assignment is acceptable because region assignment is more like a hint to the system and master doesn't have to assign a region by user requests.
          Hide
          Jimmy Xiang added a comment -

          Jeffrey Zhong, let's close this one and fix the double assignment issue in HBASE-9793. It may need some discussions.

          Show
          Jimmy Xiang added a comment - Jeffrey Zhong , let's close this one and fix the double assignment issue in HBASE-9793 . It may need some discussions.
          Hide
          Jimmy Xiang added a comment -

          I will enhance the addendum a little to have a timeout, just like in the assign case. I think we should not use runnable because the open will be retried usually. If the unassign is timed out, the pool won't be blocked.

          Show
          Jimmy Xiang added a comment - I will enhance the addendum a little to have a timeout, just like in the assign case. I think we should not use runnable because the open will be retried usually. If the unassign is timed out, the pool won't be blocked.
          Hide
          Jeffrey Zhong added a comment -

          With runnable, we can wait a little bit then resubmit it into the executor pool so that other runnable can have a chance to run. For example, a thread pool have max 5 threads if you firstly submit 5 runnable which are all long blocking like the way in the addendum and the following submitted work item won't get run until the first 5 completes even though they could complete very quickly.

          Show
          Jeffrey Zhong added a comment - With runnable, we can wait a little bit then resubmit it into the executor pool so that other runnable can have a chance to run. For example, a thread pool have max 5 threads if you firstly submit 5 runnable which are all long blocking like the way in the addendum and the following submitted work item won't get run until the first 5 completes even though they could complete very quickly.
          Hide
          Jimmy Xiang added a comment -

          There should be no stack issue since for the second call, we should get a region already in transition exception, or something else. Yes, this thread should be held for a while till the region is closed. With a runnable, it holds a thread too in waiting for the region to be closed, right? Holding a thread should be fine since this is some corner case, isn't it?

          Show
          Jimmy Xiang added a comment - There should be no stack issue since for the second call, we should get a region already in transition exception, or something else. Yes, this thread should be held for a while till the region is closed. With a runnable, it holds a thread too in waiting for the region to be closed, right? Holding a thread should be fine since this is some corner case, isn't it?
          Hide
          Jimmy Xiang added a comment -

          we may run out stack if for whatever reason we have a bad RS.

          Good point. Let me think about it.

          Show
          Jimmy Xiang added a comment - we may run out stack if for whatever reason we have a bad RS. Good point. Let me think about it.
          Hide
          Jeffrey Zhong added a comment -

          Jimmy Xiang I checked your addendum. You use recursive way to wait for a region is fully closed. There is one problem on that: The caller will be blocked for quite a while. If the call request is handled by a thread pool, we could block the thread pool. In addition, we may run out stack if for whatever reason we have a bad RS.

          I think it's better to create a runnable and resubmit the runnable to wait for the region closed and then re-assign it.

          Show
          Jeffrey Zhong added a comment - Jimmy Xiang I checked your addendum. You use recursive way to wait for a region is fully closed. There is one problem on that: The caller will be blocked for quite a while. If the call request is handled by a thread pool, we could block the thread pool. In addition, we may run out stack if for whatever reason we have a bad RS. I think it's better to create a runnable and resubmit the runnable to wait for the region closed and then re-assign it.
          Hide
          Jimmy Xiang added a comment -

          The addendum I am testing now.

          Show
          Jimmy Xiang added a comment - The addendum I am testing now.
          Hide
          Jimmy Xiang added a comment -

          Jeffrey Zhong, yes, I knew this issue. I already have something in my local branch being tested. Let me uploaded it here. Hopefully we come to the same solution.

          Show
          Jimmy Xiang added a comment - Jeffrey Zhong , yes, I knew this issue. I already have something in my local branch being tested. Let me uploaded it here. Hopefully we come to the same solution.
          Hide
          Jeffrey Zhong added a comment -

          I checked the fix and I think it opens the door for double assignment. Basically closeRegion request is processed asynchronously. Even we send close RPC to a region's host region server, the region could open on another region server before the old region server really close the region. Then we end up in double assignment issue.

          In addition, we potentially have a data loss situation. AM#forceRegionStateToOffline doesn't wait for region is fully closed. If a region is open while the old RS still flush, then some store files may not open in the new location. Even more, if the old RS crashes, the WAL splitting will be skipped then we have a permanent data loss.

          Jimmy Xiang Could you please double check the above? Meanwhile let me try to come up an addendum patch. Thanks.

          Show
          Jeffrey Zhong added a comment - I checked the fix and I think it opens the door for double assignment. Basically closeRegion request is processed asynchronously. Even we send close RPC to a region's host region server, the region could open on another region server before the old region server really close the region. Then we end up in double assignment issue. In addition, we potentially have a data loss situation. AM#forceRegionStateToOffline doesn't wait for region is fully closed. If a region is open while the old RS still flush, then some store files may not open in the new location. Even more, if the old RS crashes, the WAL splitting will be skipped then we have a permanent data loss. Jimmy Xiang Could you please double check the above? Meanwhile let me try to come up an addendum patch. Thanks.
          Hide
          Jimmy Xiang added a comment -

          Yes, that's right. It should have fixed HBASE-9777 too.

          Show
          Jimmy Xiang added a comment - Yes, that's right. It should have fixed HBASE-9777 too.
          Hide
          Hudson added a comment -

          SUCCESS: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #796 (See https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/796/)
          HBASE-9773 Master aborted when hbck asked the master to assign a region that was already online (jxiang: rev 1532633)

          • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java
          • /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestAssignmentManagerOnCluster.java
          Show
          Hudson added a comment - SUCCESS: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #796 (See https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/796/ ) HBASE-9773 Master aborted when hbck asked the master to assign a region that was already online (jxiang: rev 1532633) /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestAssignmentManagerOnCluster.java
          Hide
          Hudson added a comment -

          FAILURE: Integrated in hbase-0.96-hadoop2 #90 (See https://builds.apache.org/job/hbase-0.96-hadoop2/90/)
          HBASE-9773 Master aborted when hbck asked the master to assign a region that was already online (jxiang: rev 1532634)

          • /hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java
          • /hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestAssignmentManagerOnCluster.java
          Show
          Hudson added a comment - FAILURE: Integrated in hbase-0.96-hadoop2 #90 (See https://builds.apache.org/job/hbase-0.96-hadoop2/90/ ) HBASE-9773 Master aborted when hbck asked the master to assign a region that was already online (jxiang: rev 1532634) /hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java /hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestAssignmentManagerOnCluster.java
          Hide
          Hudson added a comment -

          SUCCESS: Integrated in hbase-0.96 #143 (See https://builds.apache.org/job/hbase-0.96/143/)
          HBASE-9773 Master aborted when hbck asked the master to assign a region that was already online (jxiang: rev 1532634)

          • /hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java
          • /hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestAssignmentManagerOnCluster.java
          Show
          Hudson added a comment - SUCCESS: Integrated in hbase-0.96 #143 (See https://builds.apache.org/job/hbase-0.96/143/ ) HBASE-9773 Master aborted when hbck asked the master to assign a region that was already online (jxiang: rev 1532634) /hbase/branches/0.96/hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java /hbase/branches/0.96/hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestAssignmentManagerOnCluster.java
          Hide
          Devaraj Das added a comment -

          Cool. Now it seems this will also fix HBASE-9777. Would it?

          Show
          Devaraj Das added a comment - Cool. Now it seems this will also fix HBASE-9777 . Would it?
          Hide
          Hudson added a comment -

          SUCCESS: Integrated in HBase-TRUNK #4622 (See https://builds.apache.org/job/HBase-TRUNK/4622/)
          HBASE-9773 Master aborted when hbck asked the master to assign a region that was already online (jxiang: rev 1532633)

          • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java
          • /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestAssignmentManagerOnCluster.java
          Show
          Hudson added a comment - SUCCESS: Integrated in HBase-TRUNK #4622 (See https://builds.apache.org/job/HBase-TRUNK/4622/ ) HBASE-9773 Master aborted when hbck asked the master to assign a region that was already online (jxiang: rev 1532633) /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestAssignmentManagerOnCluster.java
          Hide
          stack added a comment -

          Jimmy Xiang makes sense. I like the test.

          Show
          stack added a comment - Jimmy Xiang makes sense. I like the test.
          Hide
          Jimmy Xiang added a comment -

          Integrated into trunk and 0.96. Thanks Devaraj for finding the issue. Thanks Stack, Ted for reviewing the patch.

          Show
          Jimmy Xiang added a comment - Integrated into trunk and 0.96. Thanks Devaraj for finding the issue. Thanks Stack, Ted for reviewing the patch.
          Hide
          Jimmy Xiang added a comment - - edited

          Stack, if it is null, the state is managed by the caller so we leave it to the caller. If the transitionInZK is not set, the caller is just to do the best to close the region just in case to avoid double assignment. So we don't check the actual state here.

          Show
          Jimmy Xiang added a comment - - edited Stack , if it is null, the state is managed by the caller so we leave it to the caller. If the transitionInZK is not set, the caller is just to do the best to close the region just in case to avoid double assignment. So we don't check the actual state here.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12608601/trunk-9773_v2.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          +1 hadoop1.0. The patch compiles against the hadoop 1.0 profile.

          +1 hadoop2.0. The patch compiles against the hadoop 2.0 profile.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 lineLengths. The patch does not introduce lines longer than 100

          -1 site. The patch appears to cause mvn site goal to fail.

          +1 core tests. The patch passed unit tests in .

          Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//testReport/
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
          Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12608601/trunk-9773_v2.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 3 new or modified tests. +1 hadoop1.0 . The patch compiles against the hadoop 1.0 profile. +1 hadoop2.0 . The patch compiles against the hadoop 2.0 profile. +1 javadoc . The javadoc tool did not generate any warning messages. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 lineLengths . The patch does not introduce lines longer than 100 -1 site . The patch appears to cause mvn site goal to fail. +1 core tests . The patch passed unit tests in . Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/7557//console This message is automatically generated.
          Hide
          stack added a comment -

          Patch looks good Jimmy Xiang Should the state check be tighter than just checking for null? What could it be? What would be legit and what not?

          Show
          stack added a comment - Patch looks good Jimmy Xiang Should the state check be tighter than just checking for null? What could it be? What would be legit and what not?
          Hide
          Ted Yu added a comment -

          +1

          Show
          Ted Yu added a comment - +1
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12608601/trunk-9773_v2.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          +1 hadoop1.0. The patch compiles against the hadoop 1.0 profile.

          +1 hadoop2.0. The patch compiles against the hadoop 2.0 profile.

          +1 javadoc. The javadoc tool did not generate any warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 lineLengths. The patch does not introduce lines longer than 100

          -1 site. The patch appears to cause mvn site goal to fail.

          +1 core tests. The patch passed unit tests in .

          Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//testReport/
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
          Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12608601/trunk-9773_v2.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 3 new or modified tests. +1 hadoop1.0 . The patch compiles against the hadoop 1.0 profile. +1 hadoop2.0 . The patch compiles against the hadoop 2.0 profile. +1 javadoc . The javadoc tool did not generate any warning messages. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 findbugs . The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 lineLengths . The patch does not introduce lines longer than 100 -1 site . The patch appears to cause mvn site goal to fail. +1 core tests . The patch passed unit tests in . Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/7556//console This message is automatically generated.
          Hide
          Jimmy Xiang added a comment -

          Attached a wrong patch file. Here is the right one.

          Show
          Jimmy Xiang added a comment - Attached a wrong patch file. Here is the right one.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12608596/trunk-9773.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          -1 patch. The patch command could not apply the patch.

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

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12608596/trunk-9773.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 3 new or modified tests. -1 patch . The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/7555//console This message is automatically generated.
          Hide
          Jimmy Xiang added a comment -

          It's introduced by HBASE-9514 I think. I attached a patch to fix it, added a test too.

          Show
          Jimmy Xiang added a comment - It's introduced by HBASE-9514 I think. I attached a patch to fix it, added a test too.
          Hide
          Devaraj Das added a comment -

          In my analysis, it seemed this wasn't introduced by HBASE-9696 if that's what you are referring to as causing the regression..

          Show
          Devaraj Das added a comment - In my analysis, it seemed this wasn't introduced by HBASE-9696 if that's what you are referring to as causing the regression..
          Hide
          Devaraj Das added a comment -

          Regression w.r.t what?

          Show
          Devaraj Das added a comment - Regression w.r.t what?
          Hide
          Jimmy Xiang added a comment -

          This is a regression I think. I can post a patch unless someone else wants to take it.

          Show
          Jimmy Xiang added a comment - This is a regression I think. I can post a patch unless someone else wants to take it.

            People

            • Assignee:
              Jimmy Xiang
              Reporter:
              Devaraj Das
            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development