Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.99.0
    • Component/s: Client, regionserver
    • Labels:
    • Hadoop Flags:
      Reviewed
    • Tags:
      noob

      Description

      1. the checkAnd

      {Put|Delete} method that takes a CompareOP is not exposed via HTable[Interface].
      2. there is unnecessary duplicate code in the check{Put|Delete}

      code in HRegionServer.

      1. 5923-trunk.txt
        15 kB
        Lars Hofhansl
      2. 5923-0.94.txt
        12 kB
        Lars Hofhansl
      3. HBASE-10262-trunk_v0.patch
        17 kB
        Honghua Feng

        Activity

        Hide
        Lars Hofhansl added a comment -

        Here's a trunk patch.
        Not sure about importing the generated CompareType class in HTableInterface and CoprocessorHost (but I think it's OK, we're dong that in HTable too).

        Show
        Lars Hofhansl added a comment - Here's a trunk patch. Not sure about importing the generated CompareType class in HTableInterface and CoprocessorHost (but I think it's OK, we're dong that in HTable too).
        Hide
        Hadoop QA added a comment -

        +1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12525400/5923-trunk.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 hadoop23. The patch compiles against the hadoop 0.23.x 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 core tests. The patch passed unit tests in .

        Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/1741//testReport/
        Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/1741//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html
        Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/1741//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/12525400/5923-trunk.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 hadoop23. The patch compiles against the hadoop 0.23.x 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 core tests. The patch passed unit tests in . Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/1741//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/1741//artifact/trunk/patchprocess/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/1741//console This message is automatically generated.
        Hide
        stack added a comment -

        This patch is great. Thanks for going back and doing the cleanup.

        This class should not be in filter package?
        +import org.apache.hadoop.hbase.filter.WritableByteArrayComparable;

        Probably hard to move it now? Its part of a public API? Could deprecate and replace w/ a more generic, non-filter specific class? Moving it should not be part of this patch. Its not so bad anyways having this filter package pollution since its in client facing code and clients need access to filter stuff...

        Would think pollution:

        +import org.apache.hadoop.hbase.protobuf.generated.ClientProtos.Condition.CompareType;

        Should be pulling in a non-pb class into an Interface like this. Can we encapsulate these Client conditions in a non-pb class?

        Show
        stack added a comment - This patch is great. Thanks for going back and doing the cleanup. This class should not be in filter package? +import org.apache.hadoop.hbase.filter.WritableByteArrayComparable; Probably hard to move it now? Its part of a public API? Could deprecate and replace w/ a more generic, non-filter specific class? Moving it should not be part of this patch. Its not so bad anyways having this filter package pollution since its in client facing code and clients need access to filter stuff... Would think pollution: +import org.apache.hadoop.hbase.protobuf.generated.ClientProtos.Condition.CompareType; Should be pulling in a non-pb class into an Interface like this. Can we encapsulate these Client conditions in a non-pb class?
        Hide
        Lars Hofhansl added a comment -

        0.94 patch.
        Looking at the two patches now, the PB stuff is leaking through.
        I.e. in trunk the generated CompareType is used by a client, whereas 0.94 CompareFilter.compareOp has to be used.

        That also means that is 0.94 there would be a dependency on CompareFilter in HTableInterface.

        Please let me know what you think.

        Show
        Lars Hofhansl added a comment - 0.94 patch. Looking at the two patches now, the PB stuff is leaking through. I.e. in trunk the generated CompareType is used by a client, whereas 0.94 CompareFilter.compareOp has to be used. That also means that is 0.94 there would be a dependency on CompareFilter in HTableInterface. Please let me know what you think.
        Hide
        stack added a comment -

        That also means that is 0.94 there would be a dependency on CompareFilter in HTableInterface.

        Thats better than a generated pb dependency IMO. If you'd like, I can make it so you can do same or similar in trunk: i.e. not have to import generated pb but rather the filter.CompareFilter or some such similar class? Just say.

        Show
        stack added a comment - That also means that is 0.94 there would be a dependency on CompareFilter in HTableInterface. Thats better than a generated pb dependency IMO. If you'd like, I can make it so you can do same or similar in trunk: i.e. not have to import generated pb but rather the filter.CompareFilter or some such similar class? Just say.
        Hide
        Lars Hofhansl added a comment -

        Thanks Stack. These are exactly the concerns I had.

        It becomes even more pronounced when looking at the 0.94 patch, which needs to have a slightly different client facing API - since the PB stuff not exist there.

        I can see a few solutions:

        • Only allow using WritableByteArrayComparable, i.e. make it implied and don't even pass it (and hence only create the dependency for HTable but not HTableInterface).
        • As you said, have a separate CompareOp class that gets translated to the correct compareType in HTable (again would allow only HTable having the dependency, but not HTableInterface)
        Show
        Lars Hofhansl added a comment - Thanks Stack. These are exactly the concerns I had. It becomes even more pronounced when looking at the 0.94 patch, which needs to have a slightly different client facing API - since the PB stuff not exist there. I can see a few solutions: Only allow using WritableByteArrayComparable, i.e. make it implied and don't even pass it (and hence only create the dependency for HTable but not HTableInterface). As you said, have a separate CompareOp class that gets translated to the correct compareType in HTable (again would allow only HTable having the dependency, but not HTableInterface)
        Hide
        Lars Hofhansl added a comment -

        @Stack: You mean have a CompareFilter.CompareOp to o.a.h.h.p.g.ClientProtos.Condition.CompareType mapping?
        That'd be nice as the client facing interface would not change between 0.94 and trunk.
        Or have a completely separate CompareOp/CompareType class?

        Show
        Lars Hofhansl added a comment - @Stack: You mean have a CompareFilter.CompareOp to o.a.h.h.p.g.ClientProtos.Condition.CompareType mapping? That'd be nice as the client facing interface would not change between 0.94 and trunk. Or have a completely separate CompareOp/CompareType class?
        Hide
        Lars Hofhansl added a comment -

        Looking at this again.

        @Stack: How would you abstract the PB dependency in HTableInterface away in trunk?

        Show
        Lars Hofhansl added a comment - Looking at this again. @Stack: How would you abstract the PB dependency in HTableInterface away in trunk?
        Hide
        Lars Hofhansl added a comment -

        The protobuf effort fixed issue #2 (thanks Jimmy).
        Issue #1 still stands, the path accepting a compare operation along with a comparator is not exposed to HTableInterface.

        Show
        Lars Hofhansl added a comment - The protobuf effort fixed issue #2 (thanks Jimmy). Issue #1 still stands, the path accepting a compare operation along with a comparator is not exposed to HTableInterface.
        Hide
        stack added a comment -

        @Lars Would suggest we make a simple standalone class w/ nought but enum in it, the enums we need comparing. There are a few examples out there to be inspired by:

        http://docs.oracle.com/cd/E29578_01/CASAPI/cas-server-javadoc/com/endeca/itl/cas/api/ComparisonOperator.html

        http://www.openoffice.org/api/docs/common/ref/com/sun/star/sheet/ConditionOperator.html

        We'd then internally map to pb enum. Ugly but less ugly than exposing pb.

        Show
        stack added a comment - @Lars Would suggest we make a simple standalone class w/ nought but enum in it, the enums we need comparing. There are a few examples out there to be inspired by: http://docs.oracle.com/cd/E29578_01/CASAPI/cas-server-javadoc/com/endeca/itl/cas/api/ComparisonOperator.html http://www.openoffice.org/api/docs/common/ref/com/sun/star/sheet/ConditionOperator.html We'd then internally map to pb enum. Ugly but less ugly than exposing pb.
        Hide
        Lars Hofhansl added a comment -

        That works. The other problem is o.a.h.h.Filter.WritableByteArrayComparable.
        I thought I could move this to o.a.h.h.BaseWritableByteArrayComparable and have o.a.h.h.Filter.WritableByteArrayComparable be a no-op subclass, but that would change the wire protocol

        Initially I thought one could just always BinaryComparator, but especially for LESS/GREATER type operations it is important to be able to control the sort order (for example for Unicode).

        It seems I'm stumped. Either o.a.h.h.Filter.WritableByteArrayComparable has to leak up into HTableInterface, or the wire protocol changes.

        Show
        Lars Hofhansl added a comment - That works. The other problem is o.a.h.h.Filter.WritableByteArrayComparable. I thought I could move this to o.a.h.h.BaseWritableByteArrayComparable and have o.a.h.h.Filter.WritableByteArrayComparable be a no-op subclass, but that would change the wire protocol Initially I thought one could just always BinaryComparator, but especially for LESS/GREATER type operations it is important to be able to control the sort order (for example for Unicode). It seems I'm stumped. Either o.a.h.h.Filter.WritableByteArrayComparable has to leak up into HTableInterface, or the wire protocol changes.
        Hide
        Lars Hofhansl added a comment -

        There's too much discussion around this. Removing from 0.94. Might close as "won't fix" altogether.

        Show
        Lars Hofhansl added a comment - There's too much discussion around this. Removing from 0.94. Might close as "won't fix" altogether.
        Hide
        stack added a comment -

        bq ...but that would change the wire protocol

        Thats fine in 0.96, right?

        Show
        stack added a comment - bq ...but that would change the wire protocol Thats fine in 0.96, right?
        Hide
        stack added a comment -

        And, please don't close it as "won't fix"... This is really nice clean up.

        Show
        stack added a comment - And, please don't close it as "won't fix"... This is really nice clean up.
        Hide
        stack added a comment -

        I'm making this 0.96.0 critical because a bunch of work has gone into it and I think it almost there... and its nice cleanup. I'll try and carry it over the line.

        Show
        stack added a comment - I'm making this 0.96.0 critical because a bunch of work has gone into it and I think it almost there... and its nice cleanup. I'll try and carry it over the line.
        Hide
        Sergey Shelukhin added a comment -

        hmm...

        Show
        Sergey Shelukhin added a comment - hmm...
        Hide
        Lars Hofhansl added a comment -

        Removing myself for now.

        Show
        Lars Hofhansl added a comment - Removing myself for now.
        Hide
        Ted Yu added a comment -

        Lowering priority, as suggested by group discussion.

        Show
        Ted Yu added a comment - Lowering priority, as suggested by group discussion.
        Hide
        stack added a comment -

        Moving out. I love this patch but is not going to be done in time. Marking noob if someone wants to bring this home.

        Show
        stack added a comment - Moving out. I love this patch but is not going to be done in time. Marking noob if someone wants to bring this home.
        Hide
        Lars Hofhansl added a comment -

        So to reiterate the problem... If we allow LESS/GREATER, etc, we should also be able to control the comparator used. If we wanted to simplify this is a bit, we can also punt on that part for now and always use BinaryComparator for now.

        Show
        Lars Hofhansl added a comment - So to reiterate the problem... If we allow LESS/GREATER, etc, we should also be able to control the comparator used. If we wanted to simplify this is a bit, we can also punt on that part for now and always use BinaryComparator for now.
        Hide
        Honghua Feng added a comment -

        background: I created a jira HBASE-10262 for the same goal, so I move here for continuous discussion,

        If we allow control of the compareOp we need to allow for different comparators as well (for LESS, etc) Or we can punt on that and just force binary comparator as we do not for EQUAL --Lars Hofhansl

        ==> I agree above because (for trunk):
        1. only CompareOp exposed to HTable/HTableInterface interface, no proto. type introduced, so it's clean
        2. no wire protocol change, so it's lightweight
        3.non-equal comparison operations such as LESS/GREATER use implied BinaryComparator which is reasonable/acceptable

        also attach patch for HBASE-10262 here for reference, a similar patch has been applied in our internal branch and worked fine for quite a long time.

        Show
        Honghua Feng added a comment - background: I created a jira HBASE-10262 for the same goal, so I move here for continuous discussion, If we allow control of the compareOp we need to allow for different comparators as well (for LESS, etc) Or we can punt on that and just force binary comparator as we do not for EQUAL -- Lars Hofhansl ==> I agree above because (for trunk): 1. only CompareOp exposed to HTable/HTableInterface interface, no proto. type introduced, so it's clean 2. no wire protocol change, so it's lightweight 3.non-equal comparison operations such as LESS/GREATER use implied BinaryComparator which is reasonable/acceptable also attach patch for HBASE-10262 here for reference, a similar patch has been applied in our internal branch and worked fine for quite a long time.
        Hide
        Honghua Feng added a comment -

        trunk patch attached:
        1. only CompareOp introduced as new argument, not proto. CompareType
        2. LESS/GREATER use implied binary comparator
        3. no wire protocol change

        Show
        Honghua Feng added a comment - trunk patch attached: 1. only CompareOp introduced as new argument, not proto. CompareType 2. LESS/GREATER use implied binary comparator 3. no wire protocol change
        Hide
        Lars Hofhansl added a comment -

        Patch looks good. Unless somebody desperately wants this in 0.94/0.96/0.98, let's just change this in trunk.

        Show
        Lars Hofhansl added a comment - Patch looks good. Unless somebody desperately wants this in 0.94/0.96/0.98, let's just change this in trunk.
        Hide
        Honghua Feng added a comment -

        Lars Hofhansl: Sounds good

        Show
        Honghua Feng added a comment - Lars Hofhansl : Sounds good
        Hide
        Hadoop QA added a comment -

        -1 overall. Here are the results of testing the latest attachment
        http://issues.apache.org/jira/secure/attachment/12621027/HBASE-10262-trunk_v0.patch
        against trunk revision .
        ATTACHMENT ID: 12621027

        +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 hadoop1.1. The patch compiles against the hadoop 1.1 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 generated 4 release audit warnings (more than the trunk's current 0 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 failed these unit tests:
        org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort

        Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//testReport/
        Release audit warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
        Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
        Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
        Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
        Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
        Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
        Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
        Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
        Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
        Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
        Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//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/12621027/HBASE-10262-trunk_v0.patch against trunk revision . ATTACHMENT ID: 12621027 +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 hadoop1.1 . The patch compiles against the hadoop 1.1 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 generated 4 release audit warnings (more than the trunk's current 0 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 failed these unit tests: org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//testReport/ Release audit warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html Findbugs warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/8340//console This message is automatically generated.
        Hide
        Ted Yu added a comment -

        Ran the failed test locally and it passed.

        Release audit was not caused by this patch.

        Integrated to trunk.

        Show
        Ted Yu added a comment - Ran the failed test locally and it passed. Release audit was not caused by this patch. Integrated to trunk.
        Hide
        Hudson added a comment -

        SUCCESS: Integrated in HBase-TRUNK #4790 (See https://builds.apache.org/job/HBase-TRUNK/4790/)
        HBASE-5923 Cleanup checkAndXXX logic (Tedyu: rev 1555351)

        • /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTable.java
        • /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTableInterface.java
        • /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTablePool.java
        • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoprocessorHost.java
        • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/rest/client/RemoteHTable.java
        • /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
        Show
        Hudson added a comment - SUCCESS: Integrated in HBase-TRUNK #4790 (See https://builds.apache.org/job/HBase-TRUNK/4790/ ) HBASE-5923 Cleanup checkAndXXX logic (Tedyu: rev 1555351) /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTable.java /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTableInterface.java /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTablePool.java /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoprocessorHost.java /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/rest/client/RemoteHTable.java /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
        Hide
        Hudson added a comment -

        SUCCESS: Integrated in HBase-TRUNK-on-Hadoop-1.1 #42 (See https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-1.1/42/)
        HBASE-5923 Cleanup checkAndXXX logic (Tedyu: rev 1555351)

        • /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTable.java
        • /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTableInterface.java
        • /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTablePool.java
        • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoprocessorHost.java
        • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/rest/client/RemoteHTable.java
        • /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
        Show
        Hudson added a comment - SUCCESS: Integrated in HBase-TRUNK-on-Hadoop-1.1 #42 (See https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-1.1/42/ ) HBASE-5923 Cleanup checkAndXXX logic (Tedyu: rev 1555351) /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTable.java /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTableInterface.java /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTablePool.java /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoprocessorHost.java /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/rest/client/RemoteHTable.java /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java
        Hide
        Andrew Purtell added a comment -

        Unless somebody desperately wants this in 0.94/0.96/0.98, let's just change this in trunk.

        This has already been committed to trunk, so closing as Fixed.

        Committers, please resolve JIRAs after commit.

        Show
        Andrew Purtell added a comment - Unless somebody desperately wants this in 0.94/0.96/0.98, let's just change this in trunk. This has already been committed to trunk, so closing as Fixed. Committers, please resolve JIRAs after commit.

          People

          • Assignee:
            Honghua Feng
            Reporter:
            Lars Hofhansl
          • Votes:
            0 Vote for this issue
            Watchers:
            12 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development