[ 
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

        

Reply via email to