[jira] [Commented] (HBASE-6137) RegionServer-level context and start/stop life-cycle methods for observer coprocessor
[ https://issues.apache.org/jira/browse/HBASE-6137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[ https://issues.apache.org/jira/browse/HBASE-6137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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