[
https://issues.apache.org/jira/browse/HBASE-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189229#comment-14189229
]
Andrew Purtell commented on HBASE-8607:
---------------------------------------
Hi [~juwi], the approach you describe sounds good to me. I don't think anyone
else has spent substantial time thinking through the problem. If you'd like to
take this one we'd be happy to review a patch/proposal.
> 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)
