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