[
https://issues.apache.org/jira/browse/HBASE-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13672006#comment-13672006
]
Andrew Purtell commented on HBASE-8607:
---------------------------------------
As far as I know, OSGi does not support hot class replacement, but you can shut
down, reload, and restart bundles/subsystems. This will only work as far as the
interfaces and objects exchanged between the bundle and everything else doesn't
change. For this to be possible with coprocessors, we would need to I guess
refactor the server into a bundle then have coprocessors and filters also be
structured and loaded as a bundle. As an alternative to hosting HBase itself in
an OSGi runtime, we might embed the runtime as the coprocessor host and
refactor only coprocessors and filters as bundles. So that would imply some
kind of filter host environment too or a merging of filters and coprocessors.
That is not a problem per se but an incompatible change and major surgery. We
should prototype this if serious to see if an OSGi runtime (such as Apache
Felix) can actually reliably do this. I look at Eclipse as an example of OSGi
in action and wonder. When designing coprocessors we felt it easier and more
reliable to require a process reload - guaranteed to work under every
circumstance.
As to whether or not we should do a quick reload, which might possibly be
minimized to a close then reopen of a region when a coprocessor is reloaded,
consider the circumstances of hot reload of a coprocessor in a regionserver
with many ops in flight. What will the internal state of the coprocessor look
like? Will there be cross-op dependencies? Currently at the hook points we
enumerate a CopyOnWriteList to find installed coprocessors. The swap of the old
coprocessor instance for the new will be fast and lockless but will happen at
an arbitrary point in the op stream and for some brief period of time old and
new instances will be simultaneously active. Replace this with OSGi particulars
and the coprocessor side issues don't change. For this reason I think it best
to have the coprocessor lifecycle tied to the region or regionserver lifecycle
anyway.
> Run HBase server in an OSGi container
> -------------------------------------
>
> Key: HBASE-8607
> URL: https://issues.apache.org/jira/browse/HBASE-8607
> Project: HBase
> Issue Type: New Feature
> Components: regionserver
> Reporter: James Taylor
>
> Run the HBase server in an OSGi container to support updating custom filters
> and coprocessor updates without requiring a region server reboot. 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
