You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "James Taylor (JIRA)" <ji...@apache.org> on 2012/05/30 21:29:24 UTC
[jira] [Created] (HBASE-6137) RegionServer-level context and
start/stop life-cycle methods for observer coprocessor
James Taylor created HBASE-6137:
-----------------------------------
Summary: 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
[jira] [Commented] (HBASE-6137) RegionServer-level context and
start/stop life-cycle methods for observer coprocessor
Posted by "Lars Hofhansl (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (HBASE-6137) RegionServer-level context and
start/stop life-cycle methods for observer coprocessor
Posted by "ramkrishna.s.vasudevan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-6137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13287148#comment-13287148 ]
ramkrishna.s.vasudevan commented on HBASE-6137:
-----------------------------------------------
bq.There's currently no way, however, to store/share state across coprocessor invocations on the regions within a region server
Yes we were also in want of such a context share. Thanks for raising this.
> 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