[
https://issues.apache.org/jira/browse/HBASE-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875228#action_12875228
]
HBase Review Board commented on HBASE-2001:
-------------------------------------------
Message from: "Jonathan Gray" <[email protected]>
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.hbase.org/r/96/#review124
-----------------------------------------------------------
src/main/java/org/apache/hadoop/hbase/coprocessor/Coprocessor.java
<http://review.hbase.org/r/96/#comment698>
What is purpose of this?
src/main/java/org/apache/hadoop/hbase/coprocessor/Coprocessor.java
<http://review.hbase.org/r/96/#comment694>
Split decisions will not be made post-compaction as they are now after
HBASE-2375 goes in. That decision will actually be made at flush time, most
likely post-flush though we'll know at the start whether it will end up needing
to split.
src/main/java/org/apache/hadoop/hbase/coprocessor/RegionObserver.java
<http://review.hbase.org/r/96/#comment695>
So a coprocessor implementation would potentially implement Coprocessor and
RegionObserver? Notifications of higher level events happen through
Coprocessor, this is for lower level hooks? Maybe a bit more detail in class
comment to describe difference between the two interfaces.
src/main/java/org/apache/hadoop/hbase/coprocessor/RegionObserver.java
<http://review.hbase.org/r/96/#comment701>
This makes sense now reading the rest of the code. But it seems that the
Coprocessor is in fact the "observer" that just gets notified of actions while
this observer is actually the "processor" that can manipulate stuff?
src/main/java/org/apache/hadoop/hbase/coprocessor/RegionObserver.java
<http://review.hbase.org/r/96/#comment696>
And descending timestamp
src/main/java/org/apache/hadoop/hbase/coprocessor/RegionObserver.java
<http://review.hbase.org/r/96/#comment697>
This is great javadoc
src/main/java/org/apache/hadoop/hbase/coprocessor/RegionObserver.java
<http://review.hbase.org/r/96/#comment699>
Gets are called after the Get is performed, Puts and Deletes are called
before, correct?
Would there be a use case for pre-Get hook? Just wondering.
src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
<http://review.hbase.org/r/96/#comment700>
Javadoc says it's called after the split happens but before report to
master. Seems that this happens once we create the new HRegions but before we
actually do the swap. What exactly would/could a coprocessor be doing in this
window?
One thing to be aware of is the master changes coming are going to make a
split run entirely on the RS including the edits to META, closing of the
parent, and opening of the children. Where in that process would this hook
make sense?
- Jonathan
> 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.
