[
https://issues.apache.org/jira/browse/HBASE-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972336#action_12972336
]
HBase Review Board commented on HBASE-3260:
-------------------------------------------
Message from: "Gary Helmling" <[email protected]>
bq. On 2010-12-16 17:09:44, Andrew Purtell wrote:
bq. >
src/main/java/org/apache/hadoop/hbase/coprocessor/BaseEndpointCoprocessor.java,
line 66
bq. > <http://review.cloudera.org/r/1306/diff/1/?file=18379#file18379line66>
bq. >
bq. > What are these arguments about?
Those are:
- String protocol
- long clientVersion
from org.apache.hadoop.ipc.VersionedProtocol.
Will fix these up.
bq. On 2010-12-16 17:09:44, Andrew Purtell wrote:
bq. > src/main/java/org/apache/hadoop/hbase/regionserver/CoprocessorHost.java,
line 289
bq. > <http://review.cloudera.org/r/1306/diff/1/?file=18383#file18383line289>
bq. >
bq. > Should be a WARN?
Yeah, agree. Will fix.
bq. On 2010-12-16 17:09:44, Andrew Purtell wrote:
bq. > src/main/java/org/apache/hadoop/hbase/regionserver/CoprocessorHost.java,
line 305
bq. > <http://review.cloudera.org/r/1306/diff/1/?file=18383#file18383line305>
bq. >
bq. > Should be a WARN?
Yeah, will fix.
bq. On 2010-12-16 17:09:44, Andrew Purtell wrote:
bq. > src/main/java/org/apache/hadoop/hbase/regionserver/CoprocessorHost.java,
line 385
bq. > <http://review.cloudera.org/r/1306/diff/1/?file=18383#file18383line385>
bq. >
bq. > 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.
Ok will change this to a volatile boolean and repost.
- Gary
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/1306/#review2102
-----------------------------------------------------------
> 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.
