hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-6137) RegionServer-level context and start/stop life-cycle methods for observer coprocessor
Date Mon, 06 Aug 2012 18:20:03 GMT

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

Lars Hofhansl commented on HBASE-6137:

I missed this one when I filed HBASE-6505.

Not sure I understand when exactly the start/stop methods would be called.

> RegionServer-level context and start/stop life-cycle methods for observer coprocessor
> -------------------------------------------------------------------------------------
>                 Key: HBASE-6137
>                 URL: https://issues.apache.org/jira/browse/HBASE-6137
>             Project: HBase
>          Issue Type: New Feature
>          Components: coprocessors
>    Affects Versions: 0.94.0
>            Reporter: James Taylor
> Coprocessors are a great way for an application to affect server-side processing. We're
using observer coprocessors via the postScannerOpen to enable a scan to do aggregation. There's
currently no way, however, to store/share state across coprocessor invocations on the regions
within a region server. Ideally, we'd like to be able to have a context object that allows
state to be shared across coprocessor invocation for the regions on the same region server.
This would save us the setup cost for "compiling" our aggregators again for each region. Also
useful, would be:
> - a start/stop method invocation on this new region server context object before the
first region invocation and after the last region invocation on a given region server.
> - a way to pass state to the start/stop method from the client. The scan.setAttribute
works well for passing state for the invocation on each region, but ideally something that
would allow state to be passed just once per region server. One use case would be to pass
a cache of the row data for a hash join implementation, where we wouldn't want to pass this
information for every region.
> Our current work around is to either take the hit of the extra setup costs for the coprocessor
invocation on each region or use an Endpoint coprocessor to initialize state prior to the
client scan that will cause coprocessor invocations.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message