hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "HBase Review Board (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-3260) Coprocessors: Lifecycle management
Date Fri, 17 Dec 2010 01:41:02 GMT

    [ 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" <ghelmling@gmail.com>


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.


Mime
View raw message