[
https://issues.apache.org/jira/browse/HBASE-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965914#action_12965914
]
Neil Bartlett commented on HBASE-3260:
--------------------------------------
Really? Wow. I suppose I should clarify that only about 3 of those classes are
actual surface area API that you might interact with, and most of the
interfaces are listeners with one or two methods that you might want to
implement if you want to hook into specific parts of the lifecycle.
To go any further with this heavyweight vs lightweight argument though, I'd
need to understand what this community defines as heavyweight. Note though that
OSGi's roots are in embedded software. It can run on very small devices indeed.
The advantages as I see them would be:
1) Not reinventing the wheel, but instead inheriting a very robust and
production-tested solution that appears to be close to your requirements
already.
2) Ability to use existing tools for OSGi bundle creation: e.g. Bnd, Maven's
bundle plugin, extensive tooling in both Eclipse and IntelliJ.
3) Familiarity for a large number of developers, particularly within the Apache
community since many other Apache projects are using OSGi
4) Modularity. Users can structure their extensions as fine-grained modules and
even allow their extensions to be further extended by others.
5) Dynamic deployment and "hotswappability"
6) It's cool :-)
> 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.
