Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 1 Jun 2012 04:30:25 +0000 (UTC)
From: "ramkrishna.s.vasudevan (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <1144118365.25232.1338525025994.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <241561288.17877.1338406164979.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Commented] (HBASE-6137) RegionServer-level context and
 start/stop life-cycle methods for observer coprocessor
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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