[
https://issues.apache.org/jira/browse/HBASE-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875479#action_12875479
]
HBase Review Board commented on HBASE-2001:
-------------------------------------------
Message from: "Andrew Purtell" <[email protected]>
bq. On 2010-06-03 11:19:47, Jonathan Gray wrote:
bq. > src/main/java/org/apache/hadoop/hbase/coprocessor/Coprocessor.java, line
131
bq. > <http://review.hbase.org/r/96/diff/4/?file=892#file892line131>
bq. >
bq. > What is purpose of this?
Coprocessors may want to change their behavior based on different minor
versions.
bq. On 2010-06-03 11:19:47, Jonathan Gray wrote:
bq. > src/main/java/org/apache/hadoop/hbase/coprocessor/Coprocessor.java, line
189
bq. > <http://review.hbase.org/r/96/diff/4/?file=892#file892line189>
bq. >
bq. > 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.
Then this signal should shift to the flush upcall.
bq. On 2010-06-03 11:19:47, Jonathan Gray wrote:
bq. > src/main/java/org/apache/hadoop/hbase/coprocessor/RegionObserver.java,
line 32
bq. > <http://review.hbase.org/r/96/diff/4/?file=893#file893line32>
bq. >
bq. > 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.
RegionObserver used to have a cleaner distinction from Coprocessor. Initially
Coprocessor hooked internal region housekeeping; meanwhile RegionObserver
wrapped HRegionInterface.
bq. On 2010-06-03 11:19:47, Jonathan Gray wrote:
bq. > src/main/java/org/apache/hadoop/hbase/coprocessor/RegionObserver.java,
line 33
bq. > <http://review.hbase.org/r/96/diff/4/?file=893#file893line33>
bq. >
bq. > 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?
An interesting idea to consider renaming the interfaces for clarity.
bq. On 2010-06-03 11:19:47, Jonathan Gray wrote:
bq. > src/main/java/org/apache/hadoop/hbase/coprocessor/RegionObserver.java,
line 49
bq. > <http://review.hbase.org/r/96/diff/4/?file=893#file893line49>
bq. >
bq. > And descending timestamp
Got it.
bq. On 2010-06-03 11:19:47, Jonathan Gray wrote:
bq. > src/main/java/org/apache/hadoop/hbase/coprocessor/RegionObserver.java,
line 87
bq. > <http://review.hbase.org/r/96/diff/4/?file=893#file893line87>
bq. >
bq. > Gets are called after the Get is performed, Puts and Deletes are
called before, correct?
bq. >
bq. > Would there be a use case for pre-Get hook? Just wondering.
I wanted for the interface to be able to munge the result of the Get and only
was considering one "onGet". But for sure we could do "onGet" and
"onGetResult".
bq. On 2010-06-03 11:19:47, Jonathan Gray wrote:
bq. > src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java, line 694
bq. > <http://review.hbase.org/r/96/diff/4/?file=895#file895line694>
bq. >
bq. > 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?
bq. >
bq. > 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?
This is so a CP on a parent can know in advance that daughters from a split are
about to come on line, and their associated CPs are about to be initialized and
become operational. I don't know how useful this would be but it seemed a
reasonable part of the region lifecycle to intercept.
- Andrew
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.hbase.org/r/96/#review124
-----------------------------------------------------------
> 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.
