[
https://issues.apache.org/jira/browse/HBASE-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972328#action_12972328
]
HBase Review Board commented on HBASE-3260:
-------------------------------------------
Message from: "Andrew Purtell" <[email protected]>
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/1306/#review2102
-----------------------------------------------------------
Ship it!
src/main/java/org/apache/hadoop/hbase/coprocessor/BaseEndpointCoprocessor.java
<http://review.cloudera.org/r/1306/#comment6557>
What are these arguments about?
src/main/java/org/apache/hadoop/hbase/regionserver/CoprocessorHost.java
<http://review.cloudera.org/r/1306/#comment6558>
Should be a WARN?
src/main/java/org/apache/hadoop/hbase/regionserver/CoprocessorHost.java
<http://review.cloudera.org/r/1306/#comment6559>
Should be a WARN?
src/main/java/org/apache/hadoop/hbase/regionserver/CoprocessorHost.java
<http://review.cloudera.org/r/1306/#comment6560>
Since you are committing a change set in this area, Ryan suggested no need
for AtomicBoolean here, could just be plain volatile boolean. I think that's
right.
- Andrew
> 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.
