Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <22153525.274531290553339663.JavaMail.jira@thor>
Date: Tue, 23 Nov 2010 18:02:19 -0500 (EST)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Subject: [jira] Commented: (HBASE-3260) Coprocessors: Lifecycle management
In-Reply-To: <12071890.240851290459253804.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Andrew Purtell commented on HBASE-3260:
---------------------------------------

We could use something like Guice as a lightweight DI framework within HBase code in general, but I think this is orthogonal to what coprocessors tries to achieve. 

bq. But each coprocessor is currently a separate island the relationship between them seems more akin to chained servlet filters on a request than independent components.

Chained servlet filters is a good analogy. Need to add client-transparent compression support to your webapp? Register a compression filter on the chain. Need to add client-transparent value compression to your table? Register a value compression coprocessor on the region.


> 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.