hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-3260) Coprocessors: Lifecycle management
Date Thu, 02 Dec 2010 07:37:11 GMT

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

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

I would like to take a step back and consider a key motivation of the coprocessor design,
or, at least present here an analogy: We have treated HBase like an operating system kernel
(a highly concurrent performance critical thing) and coprocessors as the addition of an extension
surface in the manner usually employed with respect to OS kernels -- callouts -- the lightest
weight possible in terms of performance impact.  As stated earlier on this issue, chained
servlet filters is another good analogy. 

We are not considering something like generic DI, nor perhaps OSGi, though honestly I'm not
convinced either way on the latter point if it is useful for coprocessor lifecycle management
or not. (I thought... why not just a couple of additional upcalls? That would be enough for
my needs.) We want to provide a flexible extension surface with well defined semantics. We
do not want to force refactorings for the sake of producing the necessary layering/abstraction
for a DI point, or to separate some function into the OSGi notion of service. So then DI and
perhaps most of what benefit OSGi might bring to an application engineering context is not
applicable here. 

This approach can of course change if refactoring of HBase code to be more amenable to generic
DI and component model is the consensus way forward. Or if the core devs feel amenable to
satisfying requests for code refactoring when someone might want to extend something via the
DI approach. 

Personally I think the coprocessors approach as is has compelling benefits:

- Simplicity

- Well defined interface and semantics -- a fixed framework of extension points

- No need to involve core devs or trigger code refactoring

> 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