[ 
https://issues.apache.org/jira/browse/HBASE-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972312#action_12972312
 ] 

HBase Review Board commented on HBASE-3260:
-------------------------------------------

Message from: "Gary Helmling" <[email protected]>

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/1306/
-----------------------------------------------------------

Review request for hbase, stack and Andrew Purtell.


Summary
-------

This patch adds explicit start() and stop() methods for lifecycle management to 
the Coprocessor interface and refactors some of the Coprocessor/RegionObserver 
distinction, moving the region-related pre/post hooks that were previously in 
Coprocessor to RegionObserver.

Coprocessor is now the base interface, containing only:
 - start()
 - stop()
 - Priority enum
 - State enum

RegionObserver extends Coprocessor, and now contains the additional pre/post 
hooks, moved from Coprocessor:
 - pre/postOpen
 - pre/postClose
 - pre/postFlush
 - pre/postCompact
 - pre/postSplit

This will allow cleaner extension in the future, to allow addition of a 
MasterObserver interface, for example.

As shown above, I've also added a new Coprocessor.State enum consisting of the 
states:
UNINSTALLED -> INSTALLED -> STARTING -> ACTIVE -> STOPPING -> STOPPED

However, the UNINSTALLED/INSTALLED distinction is not particularly useful at 
the moment.  I'd appreciate other feedback on what's necessary here.  The 
current handling could make do with:
UNINSTALLED -> STARTING -> ACTIVE -> STOPPING -> UNINSTALLED (4 total states)

However, the UNINSTALLED/INSTALLED distinction may be useful if we want to add 
class level initialization in the future...


This addresses bug HBASE-3260.
    http://issues.apache.org/jira/browse/HBASE-3260


Diffs
-----

  
src/main/java/org/apache/hadoop/hbase/coprocessor/BaseEndpointCoprocessor.java 
b81a465 
  
src/main/java/org/apache/hadoop/hbase/coprocessor/BaseRegionObserverCoprocessor.java
 f022598 
  src/main/java/org/apache/hadoop/hbase/coprocessor/Coprocessor.java 7ea1c5e 
  src/main/java/org/apache/hadoop/hbase/coprocessor/RegionObserver.java 1792290 
  src/main/java/org/apache/hadoop/hbase/regionserver/CoprocessorHost.java 
f028525 
  src/test/java/org/apache/hadoop/hbase/coprocessor/SimpleRegionObserver.java 
3db4c36 
  
src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoprocessorInterface.java 
81cb75d 

Diff: http://review.cloudera.org/r/1306/diff


Testing
-------

Added tests for start() and stop() method invocation in 
org.apache.hadoop.hbase.coprocessor.TestCoprocessorInterface

The existing TestCoprocessorEndpoint, TestCoprocessorInterface, 
TestRegionObserverInterface, TestRegionObserverStacking tests continue to work. 
 I'm not seeing any new failures in the rest of the tests, but TestReplication 
is timing out for me, preventing all tests from executing.


Thanks,

Gary




> Coprocessors: Lifecycle management
> ----------------------------------
>
>                 Key: HBASE-3260
>                 URL: https://issues.apache.org/jira/browse/HBASE-3260
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Andrew Purtell
>             Fix For: 0.92.0
>
>         Attachments: statechart.png
>
>
> Considering extending CPs to the master, we have no equivalent to 
> pre/postOpen and pre/postClose as on the regionserver. We also should 
> consider how to resolve dependencies and initialization ordering if loading 
> coprocessors that depend on others. 
> OSGi (http://en.wikipedia.org/wiki/OSGi) has a lifecycle API and is familiar 
> to many Java programmers, so we propose to borrow its terminology and state 
> machine.
> A lifecycle layer manages coprocessors as they are dynamically installed, 
> started, stopped, updated and uninstalled. Coprocessors rely on the framework 
> for dependency resolution and class loading. In turn, the framework calls up 
> to lifecycle management methods in the coprocessor as needed.
> A coprocessor transitions between the below states over its lifetime:
> ||State||Description||
> |UNINSTALLED|The coprocessor implementation is not installed. This is the 
> default implicit state.|
> |INSTALLED|The coprocessor implementation has been successfully installed|
> |STARTING|A coprocessor instance is being started.|
> |ACTIVE|The coprocessor instance has been successfully activated and is 
> running.|
> |STOPPING|A coprocessor instance is being stopped.|
> See attached state diagram. Transitions to STOPPING will only happen as the 
> region is being closed. If a coprocessor throws an unhandled exception, this 
> will cause the RegionServer to close the region, stopping all coprocessor 
> instances on it. 
> Transitions from INSTALLED->STARTING and ACTIVE->STOPPING would go through 
> upcall methods into the coprocessor via the CoprocessorLifecycle interface:
> {code:java}
> public interface CoprocessorLifecycle {
>   void start(CoprocessorEnvironment env) throws IOException; 
>   void stop(CoprocessorEnvironment env) throws IOException;
> }
> {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to