Uploaded image for project: 'HBase'
  1. HBase
  2. HBASE-7180

RegionScannerImpl.next() is inefficient.

    Details

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

      Description

      We just came across a special scenario.

      For our Phoenix project (SQL runtime for HBase), we push a lot of work into HBase via coprocessors. One method is to wrap RegionScanner in coprocessor hooks and then do processing in the hook to avoid returning a lot of data to the client unnecessarily.

      In this specific case this is pretty bad. Since the wrapped RegionScanner's next() does not "know" that it is called this way is still does all of this on each invocation:

      1. Starts a RegionOperation
      2. Increments the request count
      3. set the current read point on a thread local (because generally each call could come from a different thread)
      4. Finally does the next on its StoreScanner(s)
      5. Ends the RegionOperation

      When this is done in a tight loop millions of times (as is the case for us) it starts to become significant.

      Not sure what to do about this, really. Opening this issue for discussion.

      One way is to extend the RegionScanner with an "internal" next() method of sorts, so that all this overhead can be avoided. The coprocessor could call the regular next() methods once and then just call the cheaper internal version.

      Are there better/cleaner ways?

      1. 7180-0.94-SKETCH.txt
        4 kB
        Lars Hofhansl
      2. 7180-0.94-v1.txt
        7 kB
        Lars Hofhansl
      3. 7180-0.94-v2.txt
        7 kB
        Lars Hofhansl
      4. 7180-0.94-v3.txt
        7 kB
        Lars Hofhansl
      5. 7180-0.94-v4.txt
        8 kB
        Lars Hofhansl
      6. 7180-0.94-v5.txt
        9 kB
        Lars Hofhansl
      7. 7180-0.96-v1.txt
        8 kB
        Lars Hofhansl
      8. 7180-0.96-v2.txt
        9 kB
        Lars Hofhansl
      9. 7180-0.96-v3.txt
        8 kB
        Lars Hofhansl
      10. 7180-0.96-v4.txt
        9 kB
        Lars Hofhansl

        Activity

        Hide
        lhofhansl Lars Hofhansl added a comment -

        Something nasty like this.
        There must be a cleaner way.

        Show
        lhofhansl Lars Hofhansl added a comment - Something nasty like this. There must be a cleaner way.
        Hide
        lhofhansl Lars Hofhansl added a comment -

        With this patch a RegionObserver wrapping a RegionScanner in preScannerOpen can handle the readpoint and start/close region operation itself and then call the cheaper next() on the wrapped scanner when needed.

        Show
        lhofhansl Lars Hofhansl added a comment - With this patch a RegionObserver wrapping a RegionScanner in preScannerOpen can handle the readpoint and start/close region operation itself and then call the cheaper next() on the wrapped scanner when needed.
        Hide
        lhofhansl Lars Hofhansl added a comment -

        We did an internal test here (using a count aggregator) without the patch (the coprocessor calls RegionScanner.next(...)) the test ran for 20s (0.94.3-current). With this patch (the coprocessor now sets up the readpoint once and also calls start/closeRegionOperation only once) the runtime went down to 17s. I.e. a 15% performance improvement, not quite as much as I had expected, but nothing to scoff at either. This same logic can potentially be used when scanner caching is enabled; right each call to next resets the threads readpoint though each call to next is done serially by the same thread in this scenario.

        Now this is a bit of a hack, I admit, but it does allow a coprocessor to access a RegionScanner at a slightly lower level. What are the thoughts about committing this (maybe find a better name for the new next() method)?

        Another further optimization would be to avoid using ThreadLocals to pass the readpoint through the layers, but instead pass it as method argument (that'd be a significant change).

        Show
        lhofhansl Lars Hofhansl added a comment - We did an internal test here (using a count aggregator) without the patch (the coprocessor calls RegionScanner.next(...)) the test ran for 20s (0.94.3-current). With this patch (the coprocessor now sets up the readpoint once and also calls start/closeRegionOperation only once) the runtime went down to 17s. I.e. a 15% performance improvement, not quite as much as I had expected, but nothing to scoff at either. This same logic can potentially be used when scanner caching is enabled; right each call to next resets the threads readpoint though each call to next is done serially by the same thread in this scenario. Now this is a bit of a hack, I admit, but it does allow a coprocessor to access a RegionScanner at a slightly lower level. What are the thoughts about committing this (maybe find a better name for the new next() method)? Another further optimization would be to avoid using ThreadLocals to pass the readpoint through the layers, but instead pass it as method argument (that'd be a significant change).
        Hide
        lhofhansl Lars Hofhansl added a comment -

        Slightly better patch.
        Also changes the call in RegionServer to use the cheaper version of next().

        Looking around at the code, we can also replace all the calls from the AggregationImplementation to use this cheaper next() method.

        Show
        lhofhansl Lars Hofhansl added a comment - Slightly better patch. Also changes the call in RegionServer to use the cheaper version of next(). Looking around at the code, we can also replace all the calls from the AggregationImplementation to use this cheaper next() method.
        Hide
        stack stack added a comment -

        getReadPt has to be public?

        nextInternal has to be public too?

        closeRegionOperation and startRegionOperation too?

        So CPs can get at them?

        You add KeyValue to RegionScanner when it did not need it previous. You have to?

        And a nextInternal in an Interface like RegionScanner seems wrong?

        I am for speedup but as you say, this one is ugly

        Show
        stack stack added a comment - getReadPt has to be public? nextInternal has to be public too? closeRegionOperation and startRegionOperation too? So CPs can get at them? You add KeyValue to RegionScanner when it did not need it previous. You have to? And a nextInternal in an Interface like RegionScanner seems wrong? I am for speedup but as you say, this one is ugly
        Hide
        lhofhansl Lars Hofhansl added a comment -

        Yeah I don't like it either. We somehow need to expose more internals to coprocessors in a clean way.

        • KeyValue already is needed for RegionScanner, since it extends internal scanner.
        • start/closeRegionOperation should be available to coprocessors anyway (I think). Otherwise it is hard to implement these types of things in coprocessors.
        • I mainly do not like nextInternal on the interface. Is there a better way to expose the inner workings of RegionScannerImpl to avoid expensive setup at each iteration?

        Another option is to keep the RegionScanner interface as it, and just make these methods public in RegionScannerImpl. A coprocessor can then cast the RegionScanner to RegionScannerImpl and access the stuff it needs.

        Show
        lhofhansl Lars Hofhansl added a comment - Yeah I don't like it either. We somehow need to expose more internals to coprocessors in a clean way. KeyValue already is needed for RegionScanner, since it extends internal scanner. start/closeRegionOperation should be available to coprocessors anyway (I think). Otherwise it is hard to implement these types of things in coprocessors. I mainly do not like nextInternal on the interface. Is there a better way to expose the inner workings of RegionScannerImpl to avoid expensive setup at each iteration? Another option is to keep the RegionScanner interface as it, and just make these methods public in RegionScannerImpl. A coprocessor can then cast the RegionScanner to RegionScannerImpl and access the stuff it needs.
        Hide
        lhofhansl Lars Hofhansl added a comment -

        How about another approach:

        1. introduce a RawRegionScanner interface, which extends RegionScanner.
        2. RawRegionScanner has all the additional methods on it we need.
        3. Add a getRawScannner to the RegionScanner interface.
        4. RegionScannerImpl would then implement RawRegionScanner.

        To the coprocessor framework we'd still hand a RegionScanner, but now the coprocessor can get the raw scanner via getRawScanner(). The RegionScannerImpl's implementation of getRawScanner() just returns "this".
        Is that better? Or does anybody have another a cleaner idea?

        closeRegionOperation and startRegionOperation would still need to be public, so that coprocessors can start/stop region operations.

        Show
        lhofhansl Lars Hofhansl added a comment - How about another approach: introduce a RawRegionScanner interface, which extends RegionScanner. RawRegionScanner has all the additional methods on it we need. Add a getRawScannner to the RegionScanner interface. RegionScannerImpl would then implement RawRegionScanner. To the coprocessor framework we'd still hand a RegionScanner, but now the coprocessor can get the raw scanner via getRawScanner(). The RegionScannerImpl's implementation of getRawScanner() just returns "this". Is that better? Or does anybody have another a cleaner idea? closeRegionOperation and startRegionOperation would still need to be public, so that coprocessors can start/stop region operations.
        Hide
        lhofhansl Lars Hofhansl added a comment -

        Talked to Stack and Gregory C. offline. Will use the initial approach with a better name for the "internal" next method.

        Show
        lhofhansl Lars Hofhansl added a comment - Talked to Stack and Gregory C. offline. Will use the initial approach with a better name for the "internal" next method.
        Hide
        lhofhansl Lars Hofhansl added a comment -

        Updated patch.
        Has nextRaw(...) instead of nextInternal(...).

        Show
        lhofhansl Lars Hofhansl added a comment - Updated patch. Has nextRaw(...) instead of nextInternal(...).
        Hide
        stack stack added a comment -

        +1

        Show
        stack stack added a comment - +1
        Hide
        lhofhansl Lars Hofhansl added a comment -

        Just changes a comment slightly

        Show
        lhofhansl Lars Hofhansl added a comment - Just changes a comment slightly
        Hide
        lhofhansl Lars Hofhansl added a comment -

        And a 0.96 version

        Show
        lhofhansl Lars Hofhansl added a comment - And a 0.96 version
        Hide
        lhofhansl Lars Hofhansl added a comment -

        It's slightly better if nextRaw can even avoid being synchronized (allowing the caller to control the scope of the synchronizing on the scanner object).
        I.e. a caller can synchronize once and call nextRaw 1000's of time, rather than caused 1000's of synchronized (each forcing a memory barrier)

        Show
        lhofhansl Lars Hofhansl added a comment - It's slightly better if nextRaw can even avoid being synchronized (allowing the caller to control the scope of the synchronizing on the scanner object). I.e. a caller can synchronize once and call nextRaw 1000's of time, rather than caused 1000's of synchronized (each forcing a memory barrier)
        Hide
        lhofhansl Lars Hofhansl added a comment -

        Same for trunk.
        If there're no objections this should be good to go.

        Show
        lhofhansl Lars Hofhansl added a comment - Same for trunk. If there're no objections this should be good to go.
        Hide
        lhofhansl Lars Hofhansl added a comment -

        The only last change I would make is document (in the JavaDoc) exactly what is required from a caller that calls nextRaw(). I.e.

        • set the readpoint
        • start/close the region operation
        • and synchronize on the scanner object

        Again, if there no objections, I'll do that on commit.

        Show
        lhofhansl Lars Hofhansl added a comment - The only last change I would make is document (in the JavaDoc) exactly what is required from a caller that calls nextRaw(). I.e. set the readpoint start/close the region operation and synchronize on the scanner object Again, if there no objections, I'll do that on commit.
        Hide
        hadoopqa Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12560327/7180-0.96-v2.txt
        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/3483//console

        This message is automatically generated.

        Show
        hadoopqa Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12560327/7180-0.96-v2.txt 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/3483//console This message is automatically generated.
        Hide
        lhofhansl Lars Hofhansl added a comment -

        Some imports changed since I created the patch. This patch should apply.

        Show
        lhofhansl Lars Hofhansl added a comment - Some imports changed since I created the patch. This patch should apply.
        Hide
        hadoopqa Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12560343/7180-0.96-v3.txt
        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 hadoop2.0. The patch compiles against the hadoop 2.0 profile.

        -1 javadoc. The javadoc tool appears to have generated 104 warning messages.

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

        -1 findbugs. The patch appears to introduce 23 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.mapreduce.TestHFileOutputFormat

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

        This message is automatically generated.

        Show
        hadoopqa Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12560343/7180-0.96-v3.txt 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 hadoop2.0 . The patch compiles against the hadoop 2.0 profile. -1 javadoc . The javadoc tool appears to have generated 104 warning messages. +1 javac . The applied patch does not increase the total number of javac compiler warnings. -1 findbugs . The patch appears to introduce 23 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.mapreduce.TestHFileOutputFormat Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/3484//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3484//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3484//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3484//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3484//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3484//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3484//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/3484//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/3484//console This message is automatically generated.
        Hide
        stack stack added a comment -

        The THOF failure was my fault, since fixed by addendum to hbase-7289.

        On commit change this to mvcc read point as in getMvccReadPoing rather than getReadPt?

        This was intentional?

        • public synchronized boolean next(List<KeyValue> outResults, int limit)
          + public boolean next(List<KeyValue> outResults, int limit)

        I get that you didn't want nextRaw synchronized but wasn't clear you wanted to remove it on public next too.

        Else patch looks good to me (I like the javadoc)

        Show
        stack stack added a comment - The THOF failure was my fault, since fixed by addendum to hbase-7289. On commit change this to mvcc read point as in getMvccReadPoing rather than getReadPt? This was intentional? public synchronized boolean next(List<KeyValue> outResults, int limit) + public boolean next(List<KeyValue> outResults, int limit) I get that you didn't want nextRaw synchronized but wasn't clear you wanted to remove it on public next too. Else patch looks good to me (I like the javadoc)
        Hide
        lhofhansl Lars Hofhansl added a comment -

        Yeah... That's better name.

        Sorry, should have mentioned the change to synchronized on some of the public next(...) methods.
        It was intentional... These all end up calling the same next method (which is synchronized), so they did not need to be synchronized and we avoid double synchronization (the performance gain from this will be minimal, but it is better form - I think)

        (I think at the RegionScanner level we could eventually remove all synchronization - it does not make sense for client to interleave calls to next() on the same scanner between multiple threads. But that's for another issue.)

        Show
        lhofhansl Lars Hofhansl added a comment - Yeah... That's better name. Sorry, should have mentioned the change to synchronized on some of the public next(...) methods. It was intentional... These all end up calling the same next method (which is synchronized), so they did not need to be synchronized and we avoid double synchronization (the performance gain from this will be minimal, but it is better form - I think) (I think at the RegionScanner level we could eventually remove all synchronization - it does not make sense for client to interleave calls to next() on the same scanner between multiple threads. But that's for another issue.)
        Hide
        stack stack added a comment -

        +1 on commit.

        Show
        stack stack added a comment - +1 on commit.
        Hide
        lhofhansl Lars Hofhansl added a comment -

        Also note how the nextRaw signature is different in trunk vs 0.94. The metric2 patch accidentally (it seems?) removed the KV size metric, which used to be passed via the next() method when called from the region server code.
        When that is fixed the signature needs to be changed accordingly.

        Show
        lhofhansl Lars Hofhansl added a comment - Also note how the nextRaw signature is different in trunk vs 0.94. The metric2 patch accidentally (it seems?) removed the KV size metric, which used to be passed via the next() method when called from the region server code. When that is fixed the signature needs to be changed accordingly.
        Hide
        lhofhansl Lars Hofhansl added a comment -

        Committed to 0.94 and 0.96.
        Thanks for bearing with me

        Show
        lhofhansl Lars Hofhansl added a comment - Committed to 0.94 and 0.96. Thanks for bearing with me
        Hide
        lhofhansl Lars Hofhansl added a comment -

        What I committed.

        Show
        lhofhansl Lars Hofhansl added a comment - What I committed.
        Show
        stack stack added a comment - Elliott Clark You see above comment by might Lars? https://issues.apache.org/jira/browse/HBASE-7180?focusedCommentId=13528693&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13528693
        Hide
        hudson Hudson added a comment -

        Integrated in HBase-TRUNK #3609 (See https://builds.apache.org/job/HBase-TRUNK/3609/)
        HBASE-7180 RegionScannerImpl.next() is inefficient. (Revision 1420004)

        Result = FAILURE
        larsh :
        Files :

        • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
        • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
        • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionScanner.java
        • /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoprocessorInterface.java
        Show
        hudson Hudson added a comment - Integrated in HBase-TRUNK #3609 (See https://builds.apache.org/job/HBase-TRUNK/3609/ ) HBASE-7180 RegionScannerImpl.next() is inefficient. (Revision 1420004) Result = FAILURE larsh : Files : /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionScanner.java /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoprocessorInterface.java
        Hide
        hudson Hudson added a comment -

        Integrated in HBase-0.94 #618 (See https://builds.apache.org/job/HBase-0.94/618/)
        HBASE-7180 RegionScannerImpl.next() is inefficient. (Revision 1420005)

        Result = SUCCESS
        larsh :
        Files :

        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/RegionScanner.java
        • /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoprocessorInterface.java
        Show
        hudson Hudson added a comment - Integrated in HBase-0.94 #618 (See https://builds.apache.org/job/HBase-0.94/618/ ) HBASE-7180 RegionScannerImpl.next() is inefficient. (Revision 1420005) Result = SUCCESS larsh : Files : /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/RegionScanner.java /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoprocessorInterface.java
        Hide
        hudson Hudson added a comment -

        Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #292 (See https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/292/)
        HBASE-7180 RegionScannerImpl.next() is inefficient. (Revision 1420004)

        Result = FAILURE
        larsh :
        Files :

        • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
        • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
        • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionScanner.java
        • /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoprocessorInterface.java
        Show
        hudson Hudson added a comment - Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #292 (See https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/292/ ) HBASE-7180 RegionScannerImpl.next() is inefficient. (Revision 1420004) Result = FAILURE larsh : Files : /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionScanner.java /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoprocessorInterface.java
        Hide
        hudson Hudson added a comment -

        Integrated in HBase-0.94-security #86 (See https://builds.apache.org/job/HBase-0.94-security/86/)
        HBASE-7180 RegionScannerImpl.next() is inefficient. (Revision 1420005)

        Result = SUCCESS
        larsh :
        Files :

        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/RegionScanner.java
        • /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoprocessorInterface.java
        Show
        hudson Hudson added a comment - Integrated in HBase-0.94-security #86 (See https://builds.apache.org/job/HBase-0.94-security/86/ ) HBASE-7180 RegionScannerImpl.next() is inefficient. (Revision 1420005) Result = SUCCESS larsh : Files : /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/RegionScanner.java /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoprocessorInterface.java
        Hide
        hudson Hudson added a comment -

        Integrated in HBase-0.94-security-on-Hadoop-23 #10 (See https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/10/)
        HBASE-7180 RegionScannerImpl.next() is inefficient. (Revision 1420005)

        Result = FAILURE
        larsh :
        Files :

        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
        • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/RegionScanner.java
        • /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoprocessorInterface.java
        Show
        hudson Hudson added a comment - Integrated in HBase-0.94-security-on-Hadoop-23 #10 (See https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/10/ ) HBASE-7180 RegionScannerImpl.next() is inefficient. (Revision 1420005) Result = FAILURE larsh : Files : /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/regionserver/RegionScanner.java /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoprocessorInterface.java

          People

          • Assignee:
            lhofhansl Lars Hofhansl
            Reporter:
            lhofhansl Lars Hofhansl
          • Votes:
            0 Vote for this issue
            Watchers:
            10 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development