hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Dimiduk (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-8607) Run HBase server in an OSGi container
Date Tue, 04 Jun 2013 03:55:22 GMT

    [ https://issues.apache.org/jira/browse/HBASE-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13674004#comment-13674004
] 

Nick Dimiduk commented on HBASE-8607:
-------------------------------------

bq. Running the coprocessor within the region server removes the problem of managing the life
cycle of two different processes, with all the questions of "the coprocessor takes time, is
it dead? Is it gc-ing?" (with the same questions on the coprocessor side: "I'm not called,
why?").

Coprocessors remain a reasonably advanced feature. I think the benefits to a novice user of
running coprocessors as a managed child process out-weight the pains (which are easily worked
around) for an advanced user.

bq. There might be a way to keep them inline with RS processing as observers as we have now
though, maybe using a shared memory channel.

This post [0] is an inspiring read for anyone considering an external process implementation.
We would require some work to achieve the word alignment that's critical to the performance
numbers posted here, but I think it's worth a shot.

[0]: http://psy-lob-saw.blogspot.co.uk/2013/04/lock-free-ipc-queue.html
                
> 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

Mime
View raw message