Details

    • Type: Sub-task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.94.2
    • Component/s: None
    • Labels:
      None
    • Hadoop Flags:
      Reviewed

      Description

      Provide an example of a RegionServer that listens to a ZK node to learn about what set of KVs can safely be deleted during a compaction.

      1. 6496.txt
        10 kB
        Lars Hofhansl
      2. 6496-0.94.txt
        14 kB
        Lars Hofhansl
      3. 6496-0.96.txt
        13 kB
        Lars Hofhansl
      4. 6496-0.96-v2.txt
        14 kB
        Lars Hofhansl
      5. 6496-v2.txt
        13 kB
        Lars Hofhansl

        Issue Links

          Activity

          Hide
          lhofhansl Lars Hofhansl added a comment -

          Here's a work in progress.
          It wasn't actually as straightforward as I thought, as there is no place within a RegionServer that would allow coprocessors to share some state.

          Furthermore I could not use the RegionServer's ZooKeeperWatcher as there is no way to unregister a Listener, hence as RegionObservers come and go their listeners would pile up firing uselessly and preventing the RegionObserver implementation from the being GC'd.

          So instead the RegionObserver itself is a watcher, which on other hand now leads to a Watcher per region.

          I could use some advice here, will such use of ZK scale?
          If it doesn't I could

          1. add a removeListenere method to ZooKeeperWatcher (would still need to work out how avoid many watches for the same node) or
          2. Have a way for RegionCoprocessorEnvironment to host some shared state for RegionObserver to coordinate in case such as this one. (could just be a Map that is accessible to all RegionObservers).
          Show
          lhofhansl Lars Hofhansl added a comment - Here's a work in progress. It wasn't actually as straightforward as I thought, as there is no place within a RegionServer that would allow coprocessors to share some state. Furthermore I could not use the RegionServer's ZooKeeperWatcher as there is no way to unregister a Listener, hence as RegionObservers come and go their listeners would pile up firing uselessly and preventing the RegionObserver implementation from the being GC'd. So instead the RegionObserver itself is a watcher, which on other hand now leads to a Watcher per region. I could use some advice here, will such use of ZK scale? If it doesn't I could add a removeListenere method to ZooKeeperWatcher (would still need to work out how avoid many watches for the same node) or Have a way for RegionCoprocessorEnvironment to host some shared state for RegionObserver to coordinate in case such as this one. (could just be a Map that is accessible to all RegionObservers).
          Hide
          apurtell Andrew Purtell added a comment -

          In an earlier iteration of CPs the coprocessor host provided an environment variable like facility, so for all CPs installed on a region could share state among themselves. This was a map provided by the CP host, so all CPs installed on a region could share state. We could bring that back as a map like you suggest but shared across all Observers in a RS, perhaps one map for every class that asks for it. (So, shared across the RS but private to each CP implementation.)

          It could also be useful to have a controlled facility for ZK watchers anyway:

          • Add to RegionServerServices a facility for getting ZK watchers on demand
          • Add to the RegionCoprocessorEnvironment an API for getting ZK watchers from the RS, handing them back to be reaped, and dealing with freeing up dangling resources from any CP termination / unload.
          • Extend above facility for shared watchers, one watcher per RS for a given CP, perhaps again keyed on class name.
          Show
          apurtell Andrew Purtell added a comment - In an earlier iteration of CPs the coprocessor host provided an environment variable like facility, so for all CPs installed on a region could share state among themselves. This was a map provided by the CP host, so all CPs installed on a region could share state. We could bring that back as a map like you suggest but shared across all Observers in a RS, perhaps one map for every class that asks for it. (So, shared across the RS but private to each CP implementation.) It could also be useful to have a controlled facility for ZK watchers anyway: Add to RegionServerServices a facility for getting ZK watchers on demand Add to the RegionCoprocessorEnvironment an API for getting ZK watchers from the RS, handing them back to be reaped, and dealing with freeing up dangling resources from any CP termination / unload. Extend above facility for shared watchers, one watcher per RS for a given CP, perhaps again keyed on class name.
          Hide
          lhofhansl Lars Hofhansl added a comment -

          Extend above facility for shared watchers, one watcher per RS for a given CP, perhaps again keyed on class name.

          I like this one. In this case the hooks implemented by the region observer are in a critical path (at least preStoreScannerOpen is), so I do not want to call zk.getData(...) in that hook, and hence the need for a watcher to be asynchronously notified of changes.
          Each RegionObserver instance would need to be notified about this, and if I understand the code right there is always exactly one instance per Region for which the observer is loaded. So sharing a single watcher with a listener for each CP would be ideal.

          We could bring that back as a map like you suggest but shared across all Observers in a RS, perhaps one map for every class that asks for it

          That seems generally useful, and maybe even better suited for the problem mentioned above. A CP would check whether a watcher has been created (an object in that shared map), create one if not, and then add a listener. The watcher would need to support removing listeners.
          With that CPs would be able to coordinate among themselves. It's not hard to make a ZK watcher, so the generality of this might be better.
          We have found need for this in other projects, but so far have worked around it.

          How would that shared be exposed to a RegionObserver? Via the RegionCoprocessorEnvironment, or the CoprocessorContext?

          Show
          lhofhansl Lars Hofhansl added a comment - Extend above facility for shared watchers, one watcher per RS for a given CP, perhaps again keyed on class name. I like this one. In this case the hooks implemented by the region observer are in a critical path (at least preStoreScannerOpen is), so I do not want to call zk.getData(...) in that hook, and hence the need for a watcher to be asynchronously notified of changes. Each RegionObserver instance would need to be notified about this, and if I understand the code right there is always exactly one instance per Region for which the observer is loaded. So sharing a single watcher with a listener for each CP would be ideal. We could bring that back as a map like you suggest but shared across all Observers in a RS, perhaps one map for every class that asks for it That seems generally useful, and maybe even better suited for the problem mentioned above. A CP would check whether a watcher has been created (an object in that shared map), create one if not, and then add a listener. The watcher would need to support removing listeners. With that CPs would be able to coordinate among themselves. It's not hard to make a ZK watcher, so the generality of this might be better. We have found need for this in other projects, but so far have worked around it. How would that shared be exposed to a RegionObserver? Via the RegionCoprocessorEnvironment, or the CoprocessorContext?
          Hide
          apurtell Andrew Purtell added a comment -

          How would that shared be exposed to a RegionObserver? Via the RegionCoprocessorEnvironment, or the CoprocessorContext?

          I was thinking addition to interface CoprocessorEnvironment or RegionCoprocessorEnvironment and implementation in RegionCoprocessorHost.

          Context is meant to hold state scoped to the invocation of a CP chain on a particular hook.

          Show
          apurtell Andrew Purtell added a comment - How would that shared be exposed to a RegionObserver? Via the RegionCoprocessorEnvironment, or the CoprocessorContext? I was thinking addition to interface CoprocessorEnvironment or RegionCoprocessorEnvironment and implementation in RegionCoprocessorHost. Context is meant to hold state scoped to the invocation of a CP chain on a particular hook.
          Hide
          lhofhansl Lars Hofhansl added a comment -

          That makes sense. Then the only part is cleanup. CP classes are not unloaded, right?
          So the onus would have to be on the CP implementation to the right thing in start/stop.

          Show
          lhofhansl Lars Hofhansl added a comment - That makes sense. Then the only part is cleanup. CP classes are not unloaded, right? So the onus would have to be on the CP implementation to the right thing in start/stop.
          Hide
          lhofhansl Lars Hofhansl added a comment - - edited

          I created HBASE-6505.

          Show
          lhofhansl Lars Hofhansl added a comment - - edited I created HBASE-6505 .
          Hide
          apurtell Andrew Purtell added a comment -

          CP classes are not unloaded, right?

          Correct.

          But they can be blacklisted via removal from the list of active loaded coprocessors if they throw an Error. See CoprocessorHost#handleCoprocessorThrowable.

          The CoprocessorHost should clean up if the CP doesn't, or can't (due to deregistration).

          Show
          apurtell Andrew Purtell added a comment - CP classes are not unloaded, right? Correct. But they can be blacklisted via removal from the list of active loaded coprocessors if they throw an Error. See CoprocessorHost#handleCoprocessorThrowable. The CoprocessorHost should clean up if the CP doesn't, or can't (due to deregistration).
          Hide
          lhofhansl Lars Hofhansl added a comment -

          Here's a patch based on HBASE-6505.
          All CP instances will use a single watcher, which keeps the date up to date asynchronously.
          If the watcher get disconnected from ZK it will try reconnect periodically.

          Show
          lhofhansl Lars Hofhansl added a comment - Here's a patch based on HBASE-6505 . All CP instances will use a single watcher, which keeps the date up to date asynchronously. If the watcher get disconnected from ZK it will try reconnect periodically.
          Hide
          zhihyu@ebaysf.com Ted Yu added a comment - - edited

          In process():

          +      } catch (InterruptedException ix) {
          +      } catch (KeeperException kx) {
          

          Please restore interrupt status above.

          License header missing in several files.

          +      // there is a short race here
          +      // in the worst case we create a watcher that will be notified once
          +      re.getSharedData().putIfAbsent(
          

          Should shared data provide putIfAbsent() functionality ?

          Show
          zhihyu@ebaysf.com Ted Yu added a comment - - edited In process(): + } catch (InterruptedException ix) { + } catch (KeeperException kx) { Please restore interrupt status above. License header missing in several files. + // there is a short race here + // in the worst case we create a watcher that will be notified once + re.getSharedData().putIfAbsent( Should shared data provide putIfAbsent() functionality ?
          Hide
          lhofhansl Lars Hofhansl added a comment -

          Thanks Ted,

          Yep, will add the license header. This was just to get a general feeling for whether the logic is even correct... Dealing with ZK correctly is tricky.

          Should shared data provide putIfAbsent() functionality ?

          Not sure what you mean. It does (the interface it exposes is a ConcurrentMap as per HBASE-6505). Do you think it should not?

          Will add Thread.interrupt (I keep forgetting about that ).

          Show
          lhofhansl Lars Hofhansl added a comment - Thanks Ted, Yep, will add the license header. This was just to get a general feeling for whether the logic is even correct... Dealing with ZK correctly is tricky. Should shared data provide putIfAbsent() functionality ? Not sure what you mean. It does (the interface it exposes is a ConcurrentMap as per HBASE-6505 ). Do you think it should not? Will add Thread.interrupt (I keep forgetting about that ).
          Hide
          zhihyu@ebaysf.com Ted Yu added a comment -

          w.r.t. putIfAbsent(), I meant if you use re.getSharedData().putIfAbsent() directly, you don't need the containsKey() check.
          ZKWatcher needs to be disposed of in case an entry already existed in shared data.

          Show
          zhihyu@ebaysf.com Ted Yu added a comment - w.r.t. putIfAbsent(), I meant if you use re.getSharedData().putIfAbsent() directly, you don't need the containsKey() check. ZKWatcher needs to be disposed of in case an entry already existed in shared data.
          Hide
          zhihyu@ebaysf.com Ted Yu added a comment - - edited

          Unnecessary ZKWatcher creation / disposal can be avoided if you have a singleton ZKWatcher to be placed into shared data map first.
          If the placement was successful, a new ZKWatcher can be created and replace the singleton for the same key.

          Show
          zhihyu@ebaysf.com Ted Yu added a comment - - edited Unnecessary ZKWatcher creation / disposal can be avoided if you have a singleton ZKWatcher to be placed into shared data map first. If the placement was successful, a new ZKWatcher can be created and replace the singleton for the same key.
          Hide
          lhofhansl Lars Hofhansl added a comment -

          @Ted: I see...
          There is no reliable way to have a singleton, though, since the instances could potentially have been loaded by separate classloaders.

          Hence the containsKey() check to avoid creating a ZKWatcher unless necessary. The putIfAbsent just guards against the short race that another CP created the shared ZK between the contains check and the put.
          Could also synchronize on this CP's sharedData; that would be the equivalent of a class lock. Taking the rare chance of unnecessarily creating a ZKWatcher seemed to be better approach.

          Show
          lhofhansl Lars Hofhansl added a comment - @Ted: I see... There is no reliable way to have a singleton, though, since the instances could potentially have been loaded by separate classloaders. Hence the containsKey() check to avoid creating a ZKWatcher unless necessary. The putIfAbsent just guards against the short race that another CP created the shared ZK between the contains check and the put. Could also synchronize on this CP's sharedData; that would be the equivalent of a class lock. Taking the rare chance of unnecessarily creating a ZKWatcher seemed to be better approach.
          Hide
          zhihyu@ebaysf.com Ted Yu added a comment -

          potentially have been loaded by separate classloaders

          One singleton (marker) per classloader is not too bad, IMHO.

          Show
          zhihyu@ebaysf.com Ted Yu added a comment - potentially have been loaded by separate classloaders One singleton (marker) per classloader is not too bad, IMHO.
          Hide
          lhofhansl Lars Hofhansl added a comment -

          I don't think statics are advised in coprocessor, and thus providing an example using them is setting the wrong expectations.

          Do you think the current way I have it is bad?

          Show
          lhofhansl Lars Hofhansl added a comment - I don't think statics are advised in coprocessor, and thus providing an example using them is setting the wrong expectations. Do you think the current way I have it is bad?
          Hide
          zhihyu@ebaysf.com Ted Yu added a comment -

          @Lars:
          The current way is fine too.

          Show
          zhihyu@ebaysf.com Ted Yu added a comment - @Lars: The current way is fine too.
          Hide
          lhofhansl Lars Hofhansl added a comment -

          OK... If there is no objections I would like to commit this soon.

          Show
          lhofhansl Lars Hofhansl added a comment - OK... If there is no objections I would like to commit this soon.
          Hide
          stack stack added a comment -

          +1 on commit. Add licenses on commit.

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

          Patch rebased for 0.96.

          Show
          lhofhansl Lars Hofhansl added a comment - Patch rebased for 0.96.
          Hide
          lhofhansl Lars Hofhansl added a comment -

          And finally a version with licenses.

          Show
          lhofhansl Lars Hofhansl added a comment - And finally a version with licenses.
          Hide
          lhofhansl Lars Hofhansl added a comment -

          And an 0.94 patch

          Show
          lhofhansl Lars Hofhansl added a comment - And an 0.94 patch
          Hide
          lhofhansl Lars Hofhansl added a comment -

          Committed to 0.94 and 0.96.

          Show
          lhofhansl Lars Hofhansl added a comment - Committed to 0.94 and 0.96.
          Hide
          hudson Hudson added a comment -

          Integrated in HBase-TRUNK #3273 (See https://builds.apache.org/job/HBase-TRUNK/3273/)
          HBASE-6496 Example ZK based scan policy (Revision 1377156)

          Result = FAILURE
          larsh :
          Files :

          • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/example
          • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/example/ZooKeeperScanPolicyObserver.java
          • /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/example
          • /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java
          Show
          hudson Hudson added a comment - Integrated in HBase-TRUNK #3273 (See https://builds.apache.org/job/HBase-TRUNK/3273/ ) HBASE-6496 Example ZK based scan policy (Revision 1377156) Result = FAILURE larsh : Files : /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/example /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/example/ZooKeeperScanPolicyObserver.java /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/example /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java
          Hide
          zhihyu@ebaysf.com Ted Yu added a comment -

          I don't see QA report in this JIRA.

          TestZooKeeperScanPolicyObserver lacks test category (https://builds.apache.org/view/G-L/view/HBase/job/HBase-TRUNK/3273/testReport/org.apache.hadoop.hbase/TestCheckTestClasses/checkClasses/):

          java.lang.AssertionError: There are 1 test classes without category: [class org.apache.hadoop.hbase.coprocessor.example.TestZooKeeperScanPolicyObserver]
          	at org.junit.Assert.fail(Assert.java:93)
          	at org.junit.Assert.assertTrue(Assert.java:43)
          	at org.apache.hadoop.hbase.TestCheckTestClasses.checkClasses(TestCheckTestClasses.java:58)
          
          Show
          zhihyu@ebaysf.com Ted Yu added a comment - I don't see QA report in this JIRA. TestZooKeeperScanPolicyObserver lacks test category ( https://builds.apache.org/view/G-L/view/HBase/job/HBase-TRUNK/3273/testReport/org.apache.hadoop.hbase/TestCheckTestClasses/checkClasses/): java.lang.AssertionError: There are 1 test classes without category: [class org.apache.hadoop.hbase.coprocessor.example.TestZooKeeperScanPolicyObserver] at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.apache.hadoop.hbase.TestCheckTestClasses.checkClasses(TestCheckTestClasses.java:58)
          Hide
          lhofhansl Lars Hofhansl added a comment -

          I didn't run HadoopQA on all new code (I ran the added test locally).
          Will add the test category.

          Show
          lhofhansl Lars Hofhansl added a comment - I didn't run HadoopQA on all new code (I ran the added test locally). Will add the test category.
          Hide
          hudson Hudson added a comment -

          Integrated in HBase-0.94 #432 (See https://builds.apache.org/job/HBase-0.94/432/)
          HBASE-6496 Example ZK based scan policy (Revision 1377155)

          Result = SUCCESS
          larsh :
          Files :

          • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/coprocessor/example
          • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/coprocessor/example/ZooKeeperScanPolicyObserver.java
          • /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/example
          • /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java
          Show
          hudson Hudson added a comment - Integrated in HBase-0.94 #432 (See https://builds.apache.org/job/HBase-0.94/432/ ) HBASE-6496 Example ZK based scan policy (Revision 1377155) Result = SUCCESS larsh : Files : /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/coprocessor/example /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/coprocessor/example/ZooKeeperScanPolicyObserver.java /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/example /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java
          Hide
          hudson Hudson added a comment -

          Integrated in HBase-TRUNK #3274 (See https://builds.apache.org/job/HBase-TRUNK/3274/)
          HBASE-6496 Addendum - add test category (Revision 1377178)

          Result = FAILURE
          larsh :
          Files :

          • /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java
          Show
          hudson Hudson added a comment - Integrated in HBase-TRUNK #3274 (See https://builds.apache.org/job/HBase-TRUNK/3274/ ) HBASE-6496 Addendum - add test category (Revision 1377178) Result = FAILURE larsh : Files : /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java
          Hide
          hudson Hudson added a comment -

          Integrated in HBase-0.94 #433 (See https://builds.apache.org/job/HBase-0.94/433/)
          HBASE-6496 Addendum - add test category (Revision 1377177)

          Result = FAILURE
          larsh :
          Files :

          • /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java
          Show
          hudson Hudson added a comment - Integrated in HBase-0.94 #433 (See https://builds.apache.org/job/HBase-0.94/433/ ) HBASE-6496 Addendum - add test category (Revision 1377177) Result = FAILURE larsh : Files : /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java
          Hide
          hudson Hudson added a comment -

          Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #147 (See https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/147/)
          HBASE-6496 Addendum - add test category (Revision 1377178)
          HBASE-6496 Example ZK based scan policy (Revision 1377156)

          Result = FAILURE
          larsh :
          Files :

          • /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java

          larsh :
          Files :

          • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/example
          • /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/example/ZooKeeperScanPolicyObserver.java
          • /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/example
          • /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java
          Show
          hudson Hudson added a comment - Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #147 (See https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/147/ ) HBASE-6496 Addendum - add test category (Revision 1377178) HBASE-6496 Example ZK based scan policy (Revision 1377156) Result = FAILURE larsh : Files : /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java larsh : Files : /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/example /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/example/ZooKeeperScanPolicyObserver.java /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/example /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java
          Hide
          hudson Hudson added a comment -

          Integrated in HBase-0.94-security #50 (See https://builds.apache.org/job/HBase-0.94-security/50/)
          HBASE-6496 Addendum - add test category (Revision 1377177)
          HBASE-6496 Example ZK based scan policy (Revision 1377155)

          Result = FAILURE
          larsh :
          Files :

          • /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java

          larsh :
          Files :

          • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/coprocessor/example
          • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/coprocessor/example/ZooKeeperScanPolicyObserver.java
          • /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/example
          • /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java
          Show
          hudson Hudson added a comment - Integrated in HBase-0.94-security #50 (See https://builds.apache.org/job/HBase-0.94-security/50/ ) HBASE-6496 Addendum - add test category (Revision 1377177) HBASE-6496 Example ZK based scan policy (Revision 1377155) Result = FAILURE larsh : Files : /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java larsh : Files : /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/coprocessor/example /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/coprocessor/example/ZooKeeperScanPolicyObserver.java /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/example /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java
          Hide
          hudson Hudson added a comment -

          Integrated in HBase-0.94-security-on-Hadoop-23 #7 (See https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/7/)
          HBASE-6496 Addendum - add test category (Revision 1377177)
          HBASE-6496 Example ZK based scan policy (Revision 1377155)

          Result = FAILURE
          larsh :
          Files :

          • /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java

          larsh :
          Files :

          • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/coprocessor/example
          • /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/coprocessor/example/ZooKeeperScanPolicyObserver.java
          • /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/example
          • /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java
          Show
          hudson Hudson added a comment - Integrated in HBase-0.94-security-on-Hadoop-23 #7 (See https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/7/ ) HBASE-6496 Addendum - add test category (Revision 1377177) HBASE-6496 Example ZK based scan policy (Revision 1377155) Result = FAILURE larsh : Files : /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java larsh : Files : /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/coprocessor/example /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/coprocessor/example/ZooKeeperScanPolicyObserver.java /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/example /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/coprocessor/example/TestZooKeeperScanPolicyObserver.java
          Hide
          stack stack added a comment -

          Fix up after bulk move overwrote some 0.94.2 fix versions w/ 0.95.0 (Noticed by Lars Hofhansl)

          Show
          stack stack added a comment - Fix up after bulk move overwrote some 0.94.2 fix versions w/ 0.95.0 (Noticed by Lars Hofhansl)

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development