[
https://issues.apache.org/jira/browse/HBASE-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13674183#comment-13674183
]
Andrew Purtell edited comment on HBASE-8607 at 6/4/13 8:53 AM:
---------------------------------------------------------------
James, I think you may have missed some discussion further up on this issue.
Specifically:
{quote}
Something might worth trying out is an OSGi socket as coprocessor. Like with
HBASE-4047 where one side of the umbilical is a "normal" coprocessor, here that
is instead a shim for another piece of code that is (re)loaded as a bundle.
Would give us a sense of how workable embedding an OSGi runtime and reloading a
coprocessor might be.
{quote}
Stated a different way, we create a coprocessor that embeds an OSGi runtime,
perhaps Apache Felix. This coprocessor is just a shell. It is configured to
load an OSGi bundle, from another path. Handlers for all upcalls are delegated
to the loaded bundle. We can expose an Endpoint for triggering bundle reload.
So, sure, we can play around with this and see if it works, without changing
anything core, since the OSGi glue would be a coprocessor itself. What do you
think? Meet up about this some time around HBaseCon?
bq. I'm no OSGi expert, but I talked with some folks here, and it seems that we
could do what we want through OSGi and swap in new jars without requiring a
rolling restart.
Can you (or one of your folks) address this:
{quote}
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.
{quote}
What happens if a scan is in progress and Phoenix is upgraded? The new instance
would not have been around when the scanner was opened, yet it will start
getting upcalls from scanner.next(). Do we need any special considerations for
this? Or can we say that Phoenix, or any other coprocessor reloaded this way,
must handle this somehow through state sharing between instances?
was (Author: apurtell):
James, I think you may have missed some discussion further up on this
issue. Specifically:
{quote}
Something might worth trying out is an OSGi socket as coprocessor. Like with
HBASE-4047 where one side of the umbilical is a "normal" coprocessor, here that
is instead a shim for another piece of code that is (re)loaded as a bundle.
Would give us a sense of how workable embedding an OSGi runtime and reloading a
coprocessor might be.
{quote}
Stated a different way, we create a coprocessor that embeds an OSGi runtime,
perhaps Apache Felix. This coprocessor is just a shell. It is configured to
load an OSGi bundle, from another path. Handlers for all upcalls are delegated
to the loaded bundle. We can expose an Endpoint for triggering bundle reload.
So, sure, we can play around with this and see if it works, without changing
anything core, since the OSGi glue would be a coprocessor itself.
bq. I'm no OSGi expert, but I talked with some folks here, and it seems that we
could do what we want through OSGi and swap in new jars without requiring a
rolling restart.
Can you (or one of your folks) address this:
{quote}
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.
{quote}
What happens if a scan is in progress and Phoenix is upgraded? The new instance
would not have been around when the scanner was opened, yet it will start
getting upcalls from scanner.next(). Do we need any special considerations for
this? Or can we say that Phoenix, or any other coprocessor reloaded this way,
must handle this somehow through state sharing between instances?
> 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
