HBase
  1. HBase
  2. HBASE-6337

[MTTR] Remove renaming tmp log file in SplitLogManager

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.94.1, 0.95.0
    • Component/s: None
    • Labels:
      None

      Description

      As HBASE-6309 mentioned, we also encounter problem of distributed-log-splitting take much more time than matser-local-log-splitting because lots of SplitLogManager 's renaming operations when finishing task.

      Could we try to remove renaming tmp log file in SplitLogManager through splitting log to regions' recover.edits directory directly as the same as the master-local-log-splitting.

      1. 6337-94.txt
        17 kB
        Ted Yu
      2. HBASE-6337v4.patch
        18 kB
        chunhui shen
      3. HBASE-6337v3.patch
        18 kB
        chunhui shen
      4. HBASE-6337v2.patch
        18 kB
        chunhui shen
      5. HBASE-6337v1.patch
        5 kB
        chunhui shen

        Activity

        chunhui shen created issue -
        Hide
        chunhui shen added a comment -

        I will upload a patch later as a start.

        Show
        chunhui shen added a comment - I will upload a patch later as a start.
        chunhui shen made changes -
        Field Original Value New Value
        Attachment HBASE-6337v1.patch [ 12535331 ]
        Hide
        Ted Yu added a comment -

        Where does the following code from moveRecoveredEditsFromTemp() go ?

              Path dst = ZKSplitLog.stripSplitLogTempDir(rootdir, src);
              if (ZKSplitLog.isCorruptFlagFile(dst)) {
                continue;
              }
        
        Show
        Ted Yu added a comment - Where does the following code from moveRecoveredEditsFromTemp() go ? Path dst = ZKSplitLog.stripSplitLogTempDir(rootdir, src); if (ZKSplitLog.isCorruptFlagFile(dst)) { continue ; }
        Hide
        stack added a comment -

        If you are removing tmp dir, don't be half-hearted about it. Go for it Chunhui. So, for example here:

        +          if (HLogSplitter.splitLogFileToTemp(rootdir, null,
        

        ... don't pass mull but remove the tmp arg. altogether (unless you have a reason to retain it – you seem to remove tmp dir elsewhere in your patch).

        Is that all it takes?

        Does this pass tests? What about the tests that replay recovered edits. These are passing?

        Good stuff Chunhui.

        Show
        stack added a comment - If you are removing tmp dir, don't be half-hearted about it. Go for it Chunhui. So, for example here: + if (HLogSplitter.splitLogFileToTemp(rootdir, null , ... don't pass mull but remove the tmp arg. altogether (unless you have a reason to retain it – you seem to remove tmp dir elsewhere in your patch). Is that all it takes? Does this pass tests? What about the tests that replay recovered edits. These are passing? Good stuff Chunhui.
        Hide
        chunhui shen added a comment -

        @ted
        With the patch, we will split log to region's directory directory like master-local-log-splitting, so we needn't to call moveRecoveredEditsFromTemp any more, the code

        Path dst = ZKSplitLog.stripSplitLogTempDir(rootdir, src);
              if (ZKSplitLog.isCorruptFlagFile(dst)) {
                continue;
              }
        

        is used to rename tmp log file, and we will judge whether the log file is corrupted in new method

        if (ZKSplitLog.isCorrupted(rootdir, logPath.getName(), fs)) {
        +      corruptedLogs.add(logPath);
        +    } else {
        +      processedLogs.add(logPath);
        +    }
        

        @stack
        HLogSplitter.splitLogFileToTemp will be called in many tests, in order to quick solution, I just pass null rather than remove the tmp arg.

        With the patch v2, I run the tests and passed in 0.94 version.

        Show
        chunhui shen added a comment - @ted With the patch, we will split log to region's directory directory like master-local-log-splitting, so we needn't to call moveRecoveredEditsFromTemp any more, the code Path dst = ZKSplitLog.stripSplitLogTempDir(rootdir, src); if (ZKSplitLog.isCorruptFlagFile(dst)) { continue ; } is used to rename tmp log file, and we will judge whether the log file is corrupted in new method if (ZKSplitLog.isCorrupted(rootdir, logPath.getName(), fs)) { + corruptedLogs.add(logPath); + } else { + processedLogs.add(logPath); + } @stack HLogSplitter.splitLogFileToTemp will be called in many tests, in order to quick solution, I just pass null rather than remove the tmp arg. With the patch v2, I run the tests and passed in 0.94 version.
        Hide
        chunhui shen added a comment -

        Updating patch v2:
        As stack's comment, removing tmp arg in method HLogSplitter#splitLogFile;
        And removing some methods won't be called after the patch.

        Show
        chunhui shen added a comment - Updating patch v2: As stack's comment, removing tmp arg in method HLogSplitter#splitLogFile; And removing some methods won't be called after the patch.
        chunhui shen made changes -
        Attachment HBASE-6337v2.patch [ 12535613 ]
        Hide
        Lars Hofhansl added a comment -

        Let's try for 0.96 for now.

        Show
        Lars Hofhansl added a comment - Let's try for 0.96 for now.
        Lars Hofhansl made changes -
        Fix Version/s 0.96.0 [ 12320040 ]
        Hide
        Ted Yu added a comment -

        Thanks for the quick response.

        +    HLogSplitter.moveSplittedLogFile(hlogDir, oldLogDir, logfile.getPath()
        

        The past tense for verb split is split. Please remove 'ted' before Logfile in the above method name.

        If you can put the 0.94 patch onto a real cluster and collect performance numbers, that would be great.

        Show
        Ted Yu added a comment - Thanks for the quick response. + HLogSplitter.moveSplittedLogFile(hlogDir, oldLogDir, logfile.getPath() The past tense for verb split is split. Please remove 'ted' before Logfile in the above method name. If you can put the 0.94 patch onto a real cluster and collect performance numbers, that would be great.
        Hide
        Ted Yu added a comment -

        For patch v2, I got a test failure:

        testSplitLogFileFirstLineCorruptionLog(org.apache.hadoop.hbase.regionserver.wal.TestHLogSplit)  Time elapsed: 1.456 sec  <<< FAILURE!
        java.lang.AssertionError: expected:<1> but was:<0>
          at org.junit.Assert.fail(Assert.java:93)
          at org.junit.Assert.failNotEquals(Assert.java:647)
          at org.junit.Assert.assertEquals(Assert.java:128)
          at org.junit.Assert.assertEquals(Assert.java:472)
          at org.junit.Assert.assertEquals(Assert.java:456)
          at org.apache.hadoop.hbase.regionserver.wal.TestHLogSplit.testSplitLogFileFirstLineCorruptionLog(TestHLogSplit.java:1108)
        

        See if you can reproduce it.

        Show
        Ted Yu added a comment - For patch v2, I got a test failure: testSplitLogFileFirstLineCorruptionLog(org.apache.hadoop.hbase.regionserver.wal.TestHLogSplit) Time elapsed: 1.456 sec <<< FAILURE! java.lang.AssertionError: expected:<1> but was:<0> at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.hadoop.hbase.regionserver.wal.TestHLogSplit.testSplitLogFileFirstLineCorruptionLog(TestHLogSplit.java:1108) See if you can reproduce it.
        Hide
        chunhui shen added a comment -

        Updating patch v3 with Ted's comment and fix the mistake in the test when making patch for trunk from 0.94.

        I run all the tests and passed in 0.94

        @Ted
        Could you run it by HadoopQA

        Show
        chunhui shen added a comment - Updating patch v3 with Ted's comment and fix the mistake in the test when making patch for trunk from 0.94. I run all the tests and passed in 0.94 @Ted Could you run it by HadoopQA
        chunhui shen made changes -
        Attachment HBASE-6337v3.patch [ 12535622 ]
        Ted Yu made changes -
        Status Open [ 1 ] Patch Available [ 10002 ]
        Hide
        chunhui shen added a comment -

        If you can put the 0.94 patch onto a real cluster and collect performance numbers, that would be great.

        If the distributed-log-splitting's bottleneck is not on the SplitLogManager, this improvement is just reducing NN operations, else it will decrease the time of distributed-log-splitting.

        We have test for the case:
        9 regionserver, 2500 regions per hlog file, total 280 hlog files,16 ms per rename operation

        With the patch, reduce the time of distributed-log-splitting from 3+ hours to 20+ mins

        Show
        chunhui shen added a comment - If you can put the 0.94 patch onto a real cluster and collect performance numbers, that would be great. If the distributed-log-splitting's bottleneck is not on the SplitLogManager, this improvement is just reducing NN operations, else it will decrease the time of distributed-log-splitting. We have test for the case: 9 regionserver, 2500 regions per hlog file, total 280 hlog files,16 ms per rename operation With the patch, reduce the time of distributed-log-splitting from 3+ hours to 20+ mins
        Lars Hofhansl made changes -
        Fix Version/s 0.94.2 [ 12321884 ]
        Hide
        Lars Hofhansl added a comment -

        Why was the rename done in the first place? Was it so that a RegionServer does not see partially written files in .recoverededits? If that is the case, is this still safe? (Not at a computer right now, so it's possible I misunderstood the nature of the change)

        Also, didn't realize you had a 0.94 patch already. Added 0.94.2 as target.

        Show
        Lars Hofhansl added a comment - Why was the rename done in the first place? Was it so that a RegionServer does not see partially written files in .recoverededits? If that is the case, is this still safe? (Not at a computer right now, so it's possible I misunderstood the nature of the change) Also, didn't realize you had a 0.94 patch already. Added 0.94.2 as target.
        Hide
        chunhui shen added a comment -

        Why was the rename done in the first place?

        We don't split log file to tmp directory anymore, and SplitLogManager need't to rename the tmp recovered.edits files when finishing task.

        If that is the case, is this still safe?

        How unsafe happen? Region will replay edits only in initialization, so we must alreay split the logs, otherwise we won't assign the region.

        Show
        chunhui shen added a comment - Why was the rename done in the first place? We don't split log file to tmp directory anymore, and SplitLogManager need't to rename the tmp recovered.edits files when finishing task. If that is the case, is this still safe? How unsafe happen? Region will replay edits only in initialization, so we must alreay split the logs, otherwise we won't assign the region.
        Hide
        Hadoop QA added a comment -

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

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

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

        +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 generated 5 javac compiler warnings (more than the trunk's current 4 warnings).

        -1 findbugs. The patch appears to introduce 7 new Findbugs (version 1.3.9) warnings.

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

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

        Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/2349//testReport/
        Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2349//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
        Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2349//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
        Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/2349//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/12535622/HBASE-6337v3.patch against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 6 new or modified tests. +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 generated 5 javac compiler warnings (more than the trunk's current 4 warnings). -1 findbugs. The patch appears to introduce 7 new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed unit tests in . Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/2349//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2349//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2349//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/2349//console This message is automatically generated.
        Hide
        ramkrishna.s.vasudevan added a comment -

        @Chunhui
        If the region dir is deleted by CJ then in the current patch we will get IOException and splitlog may be retried? HBASE-6050 was one such situation.
        In the current code

        List<FileStatus> files = listAll(fs, stagingDir);
        

        They were doing listAll and expecting a set of files? Now we are not doing that? Is it ok?

        Show
        ramkrishna.s.vasudevan added a comment - @Chunhui If the region dir is deleted by CJ then in the current patch we will get IOException and splitlog may be retried? HBASE-6050 was one such situation. In the current code List<FileStatus> files = listAll(fs, stagingDir); They were doing listAll and expecting a set of files? Now we are not doing that? Is it ok?
        Hide
        chunhui shen added a comment -

        @ram

        If the region dir is deleted by CJ then in the current patch we will get IOException and splitlog may be retried?

        For this case, if region dir is deleted by CJ when we are appending data, we will get IOException and splitlog would retry. In the next retry splitting, we won't split log for this region through the following code:
        HLogSplitter#getRegionSplitEditsPath

         if (!fs.exists(regiondir)) {
              LOG.info("This region's directory doesn't exist: "
                  + regiondir.toString() + ". It is very likely that it was" +
                  " already split so it's safe to discard those edits.");
              return null;
            }
        

        They were doing listAll and expecting a set of files? Now we are not doing that? Is it ok?

        This operation is used to list all the recovered.edits files in the tmp directory and move them to region'dir, however now we don't split log to tmp directory, so no need to do that.

        Show
        chunhui shen added a comment - @ram If the region dir is deleted by CJ then in the current patch we will get IOException and splitlog may be retried? For this case, if region dir is deleted by CJ when we are appending data, we will get IOException and splitlog would retry. In the next retry splitting, we won't split log for this region through the following code: HLogSplitter#getRegionSplitEditsPath if (!fs.exists(regiondir)) { LOG.info( "This region's directory doesn't exist: " + regiondir.toString() + ". It is very likely that it was" + " already split so it's safe to discard those edits." ); return null ; } They were doing listAll and expecting a set of files? Now we are not doing that? Is it ok? This operation is used to list all the recovered.edits files in the tmp directory and move them to region'dir, however now we don't split log to tmp directory, so no need to do that.
        Hide
        stack added a comment -

        @Lars I'm not sure why it was done originally. Prakash was probably being cautious. As long as a region does not open before log split completes, as Chunhui says, I think we should be fine. The code as is already overwrites recovered.edits files with same sequence number (which could happen if first split failed and we then rerun it before region open). Maybe there are failure scenarios we've not yet encountered or imagined – have you tried conjure any new ones Chunhui? And don't we have tests for some common failures already? – but this approach should be fine I believe.

        Show
        stack added a comment - @Lars I'm not sure why it was done originally. Prakash was probably being cautious. As long as a region does not open before log split completes, as Chunhui says, I think we should be fine. The code as is already overwrites recovered.edits files with same sequence number (which could happen if first split failed and we then rerun it before region open). Maybe there are failure scenarios we've not yet encountered or imagined – have you tried conjure any new ones Chunhui? And don't we have tests for some common failures already? – but this approach should be fine I believe.
        Hide
        stack added a comment -

        @Chunhui The patch looks good. Thanks for all the cleanup. moveSplitLogFile could be named better since now there is no actually moving being done. Call it finishSplitLog or something? Have you checked out the open region side of the affair to see if any conditions under which we might bungle the replay of recovered.edits files? I don't think it possible as long as split finishes successfully before region opens (or we crash out the cluster if we can't split).

        Show
        stack added a comment - @Chunhui The patch looks good. Thanks for all the cleanup. moveSplitLogFile could be named better since now there is no actually moving being done. Call it finishSplitLog or something? Have you checked out the open region side of the affair to see if any conditions under which we might bungle the replay of recovered.edits files? I don't think it possible as long as split finishes successfully before region opens (or we crash out the cluster if we can't split).
        Hide
        Lars Hofhansl added a comment -

        Change itself looks to me. If the writing directly into recoverededits is not a problem: +1

        Show
        Lars Hofhansl added a comment - Change itself looks to me. If the writing directly into recoverededits is not a problem: +1
        Hide
        chunhui shen added a comment -

        Have you checked out the open region side of the affair to see if any conditions under which we might bungle the replay of recovered.edits files?

        I think it won't happen, when splitting log, the edits file is named ends with ".temp", and repalying edits will skip these files.

        Show
        chunhui shen added a comment - Have you checked out the open region side of the affair to see if any conditions under which we might bungle the replay of recovered.edits files? I think it won't happen, when splitting log, the edits file is named ends with ".temp", and repalying edits will skip these files.
        Hide
        chunhui shen added a comment -

        Uploading patch v4 : Rename method name moveSplitLogFile to finishSplitLogFile

        Show
        chunhui shen added a comment - Uploading patch v4 : Rename method name moveSplitLogFile to finishSplitLogFile
        chunhui shen made changes -
        Attachment HBASE-6337v4.patch [ 12535776 ]
        Hide
        Hadoop QA added a comment -

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

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

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

        +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 generated 5 javac compiler warnings (more than the trunk's current 4 warnings).

        -1 findbugs. The patch appears to introduce 8 new Findbugs (version 1.3.9) warnings.

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

        -1 core tests. The patch failed these unit tests:
        org.apache.hadoop.hbase.regionserver.wal.TestHLog

        Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/2355//testReport/
        Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2355//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
        Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2355//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
        Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/2355//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/12535776/HBASE-6337v4.patch against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 6 new or modified tests. +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 generated 5 javac compiler warnings (more than the trunk's current 4 warnings). -1 findbugs. The patch appears to introduce 8 new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed these unit tests: org.apache.hadoop.hbase.regionserver.wal.TestHLog Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/2355//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2355//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/2355//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/2355//console This message is automatically generated.
        Hide
        Ted Yu added a comment -

        I ran TestHLog with patch v4 3 times and they passed on MacBook.

        It is a pity that builds on PreCommit-HBASE-Build were truncated to July 4th - the first link above is no longer working.

        Looks like Chunhui has answered all the questions.
        The 0.94 equivalent of the patch was running in their dev cluster.

        Will wait for 24 hours for further comments.

        Show
        Ted Yu added a comment - I ran TestHLog with patch v4 3 times and they passed on MacBook. It is a pity that builds on PreCommit-HBASE-Build were truncated to July 4th - the first link above is no longer working. Looks like Chunhui has answered all the questions. The 0.94 equivalent of the patch was running in their dev cluster. Will wait for 24 hours for further comments.
        Hide
        Lars Hofhansl added a comment -

        +1 on patch, +1 for 0.94 (can pull back into 0.94.1)

        Show
        Lars Hofhansl added a comment - +1 on patch, +1 for 0.94 (can pull back into 0.94.1)
        Ted Yu made changes -
        Status Patch Available [ 10002 ] Open [ 1 ]
        Hide
        Ted Yu added a comment -

        Patch for 0.94

        Show
        Ted Yu added a comment - Patch for 0.94
        Ted Yu made changes -
        Attachment 6337-94.txt [ 12535933 ]
        Hide
        Ted Yu added a comment -

        I am running test suite for 0.94

        Will report back if there is any test failure.

        Show
        Ted Yu added a comment - I am running test suite for 0.94 Will report back if there is any test failure.
        Hide
        Ted Yu added a comment -

        Here is test result for 0.94:

        Tests run: 648, Failures: 0, Errors: 0, Skipped: 2
        
        [INFO] ------------------------------------------------------------------------
        [INFO] BUILD SUCCESS
        [INFO] ------------------------------------------------------------------------
        [INFO] Total time: 30:14.639s
        [INFO] Finished at: Tue Jul 10 15:16:19 GMT-07:00 2012
        
        Show
        Ted Yu added a comment - Here is test result for 0.94: Tests run: 648, Failures: 0, Errors: 0, Skipped: 2 [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 30:14.639s [INFO] Finished at: Tue Jul 10 15:16:19 GMT-07:00 2012
        Hide
        Lars Hofhansl added a comment -

        Ship it.

        Show
        Lars Hofhansl added a comment - Ship it.
        Lars Hofhansl made changes -
        Fix Version/s 0.94.1 [ 12320257 ]
        Fix Version/s 0.94.2 [ 12321884 ]
        Hide
        Ted Yu added a comment -

        Ran 0.94 test suite again.
        The tests passed.

        Integrated to 0.94 and trunk.

        Thanks for the patch, Chunhui.

        Thanks for the review, Stack, Ram and Lars.

        Show
        Ted Yu added a comment - Ran 0.94 test suite again. The tests passed. Integrated to 0.94 and trunk. Thanks for the patch, Chunhui. Thanks for the review, Stack, Ram and Lars.
        Lars Hofhansl made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Hudson added a comment -

        Integrated in HBase-0.94-security #39 (See https://builds.apache.org/job/HBase-0.94-security/39/)
        HBASE-6337 [MTTR] Remove renaming tmp log file in SplitLogManager (Chunhui) (Revision 1359959)

        Result = SUCCESS
        tedyu :
        Files :

        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/SplitLogManager.java
        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/SplitLogWorker.java
        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogSplitter.java
        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/zookeeper/ZKSplitLog.java
        • /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestHLogSplit.java
        • /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestWALReplay.java
        Show
        Hudson added a comment - Integrated in HBase-0.94-security #39 (See https://builds.apache.org/job/HBase-0.94-security/39/ ) HBASE-6337 [MTTR] Remove renaming tmp log file in SplitLogManager (Chunhui) (Revision 1359959) Result = SUCCESS tedyu : Files : /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/SplitLogManager.java /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/SplitLogWorker.java /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogSplitter.java /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/zookeeper/ZKSplitLog.java /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestHLogSplit.java /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestWALReplay.java
        Hide
        Hudson added a comment -

        Integrated in HBase-0.94-security-on-Hadoop-23 #6 (See https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/6/)
        HBASE-6337 [MTTR] Remove renaming tmp log file in SplitLogManager (Chunhui) (Revision 1359959)

        Result = FAILURE
        tedyu :
        Files :

        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/SplitLogManager.java
        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/SplitLogWorker.java
        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogSplitter.java
        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/zookeeper/ZKSplitLog.java
        • /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestHLogSplit.java
        • /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestWALReplay.java
        Show
        Hudson added a comment - Integrated in HBase-0.94-security-on-Hadoop-23 #6 (See https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/6/ ) HBASE-6337 [MTTR] Remove renaming tmp log file in SplitLogManager (Chunhui) (Revision 1359959) Result = FAILURE tedyu : Files : /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/SplitLogManager.java /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/SplitLogWorker.java /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/wal/HLogSplitter.java /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/zookeeper/ZKSplitLog.java /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestHLogSplit.java /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestWALReplay.java
        Lars Hofhansl made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        stack made changes -
        Fix Version/s 0.95.0 [ 12324094 ]
        Fix Version/s 0.96.0 [ 12320040 ]
        Fix Version/s 0.94.1 [ 12320257 ]
        Lars Hofhansl made changes -
        Fix Version/s 0.94.2 [ 12321884 ]
        Lars Hofhansl made changes -
        Fix Version/s 0.94.1 [ 12320257 ]
        Fix Version/s 0.94.2 [ 12321884 ]

          People

          • Assignee:
            chunhui shen
            Reporter:
            chunhui shen
          • Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development