hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anoop Sam John (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17732) Coprocessor Design Improvements
Date Thu, 28 Sep 2017 03:52:00 GMT

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

Anoop Sam John commented on HBASE-17732:

This is great stuff from u.   One Q...
Now we can have diff kind of Observer hooks going into diff classes. This is nice.
Can we have a way in the code (before trying to call the hook) to know
whether the user has implemented one particular hook or not?   eg:  On
write related hooks only prePut() might be what the user CP
implemented. All others are just dummy impl from the interface.   Can
we have a  way for the core code to know this and avoid the call to
other dummy hooks fully?    Some times we do some processing for just
calling CP hooks (Say we have to make a POJO out of PB object for
calling) and if the user CP not impl this hook, we can avoid this
extra work fully.    The pain of this will be more when we have to
later deprecate one hook and add new.  So the dummy impl in new hook
has to call the old one and that might be doing some extra work

If the CP f/w itself is having a way to tell this, the core code can make use.  What am expecting
is some thing like in PB way where we can call 
CPObject.hasPreXXXX(), then CPObject. preXXXX ()..   Should not like asking users to impl
this extra ugly thing.   When the CP instance is loaded in the RS/HM,  that object will be
having this info also.   Just some thinking and sharing with u.   May be for thinking and
later changes.   

Thanks for this nice refactoring.

> Coprocessor Design Improvements
> -------------------------------
>                 Key: HBASE-17732
>                 URL: https://issues.apache.org/jira/browse/HBASE-17732
>             Project: HBase
>          Issue Type: Improvement
>          Components: Coprocessors
>            Reporter: Appy
>            Assignee: Appy
>            Priority: Critical
>              Labels: incompatible
>             Fix For: 2.0.0-alpha-4
>         Attachments: HBASE-17732.master.001.patch, HBASE-17732.master.002.patch, HBASE-17732.master.003.patch,
HBASE-17732.master.004.patch, HBASE-17732.master.005.patch, HBASE-17732.master.006.patch,
HBASE-17732.master.007.patch, HBASE-17732.master.008.patch, HBASE-17732.master.009.patch,
HBASE-17732.master.010.patch, HBASE-17732.master.011.patch, HBASE-17732.master.012.patch,
HBASE-17732.master.013.patch, HBASE-17732.master.014.patch
> The two main changes are:
> * *Adding template for coprocessor type to CoprocessorEnvironment i.e. {{interface CoprocessorEnvironment<C
extends Coprocessor>}}*
>   ** Enables us to load only relevant coprocessors in hosts. Right now each type of host
loads all types of coprocs and it's only during execOperation that it checks if the coproc
is of correct type i.e. XCoprocessorHost will load XObserver, YObserver, and all others, and
will check in execOperation if {{coproc instanceOf XObserver}} and ignore the rest.
>   ** Allow sharing of a bunch functions/classes which are currently duplicated in each
host. For eg. CoprocessorOperations, CoprocessorOperationWithResult, execOperations().
> * *Introduce 4 coprocessor classes and use composition between these new classes and
and old observers*
>   ** The real gold here is, moving forward, we'll be able to break down giant everything-in-one
observers (masterobserver has 100+ functions) into smaller, more focused observers. These
smaller observer can then have different compat guarantees!!
> Here's a more detailed design doc: https://docs.google.com/document/d/1mPkM1CRRvBMZL4dBQzrus8obyvNnHhR5it2yyhiFXTg/edit?usp=sharing

This message was sent by Atlassian JIRA

View raw message