[
https://issues.apache.org/jira/browse/HBASE-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14184667#comment-14184667
]
Julian Wissmann commented on HBASE-8607:
----------------------------------------
Andrew, your suggestion sounds really interesting. I've just been thinking
about it for a while in order to estimate how big an effort prototyping this
would be. The way I understand it, the idea is, that we have an OSGi
Coprocessor, that the regular coprocessors are registered to as an OSGi
Service. However, for this to work, there will either need to be a Service
Registry on each Region or we go with Distributed OSGi and dump it in the
client. Either way, there also needs to be a mechanism to check service
availability on the Regions form the client side.
Right now, I'd consider the version with each region server holding its own
service registry to be quite feasible. I'm thinking the following approach:
The OSGi Coprocessor wil discover Bundles, the only service provided by the
Bundle will actually be starting discovered coprocessors with its own
environment. That way the client side wil be rather clean and the actual
coprocessors will behave as usual (their own protocol and client) thus allowing
for the OSGi Coprocessor to be rather simple and maximizing flexibility. The
only required client side functionality will then be representing the Service
Registry and starting region side services by name (at least I can't think of
another way considering that protobuf is in the middle of it).
Any more thoughts on this?
> 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)
