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

HBase Review Board commented on HBASE-2001:
-------------------------------------------

Message from: "Todd Lipcon" <[email protected]>

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.hbase.org/r/96/#review121
-----------------------------------------------------------


this seems like a reasonable framework, but I'd rather see this stay around as 
a branch until there is at least one or two actual things using it for a real 
purpose. Otherwise I think we'll end up shipping an API that we later realize 
doesn't work for real apps. What do you think?


src/main/java/org/apache/hadoop/hbase/coprocessor/Coprocessor.java
<http://review.hbase.org/r/96/#comment676>

    before or after reporting?



src/main/java/org/apache/hadoop/hbase/coprocessor/Coprocessor.java
<http://review.hbase.org/r/96/#comment677>

    this map-like interface is somewhat confusing - what's the purpose of it?



src/test/java/org/apache/hadoop/hbase/coprocessor/TestClassloading.java
<http://review.hbase.org/r/96/#comment678>

    woah, can we add something to the build to build this jar as a test 
resource, or something?



src/test/java/org/apache/hadoop/hbase/coprocessor/TestCoprocessorInterface.java
<http://review.hbase.org/r/96/#comment679>

    you could use mockito verification to do this, probably would be simpler


- Todd





> Coprocessors: Colocate user code with regions
> ---------------------------------------------
>
>                 Key: HBASE-2001
>                 URL: https://issues.apache.org/jira/browse/HBASE-2001
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Andrew Purtell
>            Assignee: Andrew Purtell
>         Attachments: asm-3.2-bin.zip, asm-transformations.pdf, 
> HBASE-2001-RegionObserver.patch, HBASE-2001.patch.gz
>
>
> Support user code that runs run next to each region in table. As regions 
> split and move, coprocessor code should automatically  move also.
> Use classloader which looks on HDFS.
> Associate a list of classes to load with each table. Put this in HRI so it 
> inherits from table but can be changed on a per region basis (so then those 
> region specific changes can inherited by daughters). 
> Not completely arbitrary code, should require implementation of an interface 
> with callbacks for:
> * Open
> * Close
> * Split
> * Compact
> * (Multi)get and scanner next()
> * (Multi)put
> * (Multi)delete
> Add method to HRegionInterface for invoking coprocessor methods and 
> retrieving results.  
> Add methods in o.a.h.h.regionserver or subpackage which implement convenience 
> functions for coprocessor methods and consistent/controlled access to 
> internals: store access, threading, persistent and ephemeral state, scratch 
> storage, etc. 
> GitHub: http://github.com/apurtell/hbase-coprocessor

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to