[
https://issues.apache.org/jira/browse/HBASE-3260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12935096#action_12935096
]
Gary Helmling commented on HBASE-3260:
--------------------------------------
I agree we should standardize the terminology between here and server lifecycle
management.
I remember in the RS and master lifecycle discussion seeing a mention of the
Google guava Service interface:
http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/base/Service.html
It uses similar start() and stop() methods, with a very similar set of states,
should RS and master go that route.
I'm hesitant to bring in anything too heavy weight (really more than feather
weight) to assist with this. I'm not super familiar with the OSGi landscape
but a lot of what I'm seeing seems to be big "component framework servers" that
load and run everything, so I'm not optimistic we'll find an easy lib that fits
our bill. But I'm open to any suggestions from others more knowledgeable.
The DI thought is interesting, but I'm not sure coprocessors would be a great
fit for those tools. We currently provide access to needed services through
the CoprocessorEnvironment interface, which DI could certainly replace. 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. For the moment we're trying to avoid direct class references
between coprocessors so that we can better isolate the class loading, allowing
us to do code weaving on class loading to enforce resource utilization
throttling.
Are there other aspects you can see DI providing? Maybe I'm seeing things the
wrong way? And any suggestions on very light weight libs for assisting?
> 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.
