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