[
https://issues.apache.org/jira/browse/HBASE-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14210032#comment-14210032
]
Julian Wissmann commented on HBASE-8607:
----------------------------------------
Hi,
Sorry about the late reply. Time is a little scarce at the moment.
It'll take me a few weeks to get this going as it will really just be a little
side project, but sure, I'll be happy to work on this and provide a patch.
> Allow custom filters and coprocessors to be updated for a region server
> without requiring a restart
> ---------------------------------------------------------------------------------------------------
>
> Key: HBASE-8607
> URL: https://issues.apache.org/jira/browse/HBASE-8607
> Project: HBase
> Issue Type: New Feature
> Components: regionserver
> Reporter: James Taylor
>
> One solution to allowing custom filters and coprocessors to be updated for a
> region server without requiring a restart might be to run the HBase server in
> an OSGi container (maybe there are other approaches as well?). Typically,
> applications that use coprocessors and custom filters also have shared
> classes underneath, so putting the burden on the user to include some kind of
> version name in the class is not adequate. Including the version name in the
> package might work in some cases (at least until dependent jars start to
> change as well), but is cumbersome and overburdens the app developer.
> Regardless of what approach is taken, we'd need to define the life cycle of
> the coprocessors and custom filters when a new version is loaded. For
> example, in-flight invocations could continue to use the old version while
> new invocations would use the new ones. Once the in-flight invocations are
> complete, the old code/jar could be unloaded.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
