hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-8607) Run HBase server in an OSGi container
Date Sat, 01 Jun 2013 07:24:20 GMT

    [ 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

View raw message