You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@hbase.apache.org by Stephen Jiang <sy...@gmail.com> on 2016/04/28 18:06:57 UTC

coprocessors in split region

during split region, we have a lot of coprocessors in
RegionCoprocessorHost  (some of them were added by
https://issues.apache.org/jira/browse/HBASE-6633)

  public void preSplit(final byte[] splitRow) throws IOException {}
  public void postSplit(final Region l, final Region r) throws IOException
{}
  public boolean preSplitBeforePONR(final byte[] splitKey,
      final List<Mutation> metaEntries) throws IOException {}
  public void preSplitAfterPONR() throws IOException {}
  public void preRollBackSplit() throws IOException {}
  public void postRollBackSplit() throws IOException {}
  public void postCompleteSplit() throws IOException {}

I am in the process of moving split region a procedure-based from MASTER,
which means I should move those coprocessors to MasterCoprocessorHost.

Looking at the names, it seems to me that we exposed PONR implementation
details of split operation (what if we don't have PONR in future
implementation?  what if a new implementation always PONR from the
beginning).   I just wondering whether any customer leverage all the
coprocessors in split?

Also anyone sees any problem moving those CP to Master?  Your insight is
helpful.

Thanks
Stephen

Re: coprocessors in split region

Posted by Ted Yu <yu...@gmail.com>.

Looks like Phoenix makes use of PONR methods:

phoenix-core/src/main/java/org/apache/hadoop/hbase/regionserver/IndexSplitTransaction.java:
     this.parent.getCoprocessorHost().preSplitAfterPONR();
phoenix-core/src/main/java/org/apache/hadoop/hbase/regionserver/LocalIndexSplitter.java:
   public void
preSplitAfterPONR(ObserverContext<RegionCoprocessorEnvironment> ctx)
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/DelegateRegionObserver.java:
   public void
preSplitAfterPONR(ObserverContext<RegionCoprocessorEnvironment> ctx)
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/DelegateRegionObserver.java:
       delegate.preSplitAfterPONR(ctx);

phoenix-core/src/main/java/org/apache/hadoop/hbase/regionserver/IndexSplitTransaction.java:
         preSplitBeforePONR(this.splitrow, metaEntries)) {
phoenix-core/src/main/java/org/apache/hadoop/hbase/regionserver/LocalIndexSplitter.java:
   public void
preSplitBeforePONR(ObserverContext<RegionCoprocessorEnvironment> ctx,
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/DelegateRegionObserver.java:
   public void
preSplitBeforePONR(ObserverContext<RegionCoprocessorEnvironment> ctx,
phoenix-core/src/main/java/org/apache/phoenix/coprocessor/DelegateRegionObserver.java:
       delegate.preSplitBeforePONR(ctx, splitKey, metaEntries);

FYI

On Thu, Apr 28, 2016 at 9:06 AM, Stephen Jiang <sy...@gmail.com>
wrote:

> during split region, we have a lot of coprocessors in
> RegionCoprocessorHost  (some of them were added by
> https://issues.apache.org/jira/browse/HBASE-6633)
>
>   public void preSplit(final byte[] splitRow) throws IOException {}
>   public void postSplit(final Region l, final Region r) throws IOException
> {}
>   public boolean preSplitBeforePONR(final byte[] splitKey,
>       final List<Mutation> metaEntries) throws IOException {}
>   public void preSplitAfterPONR() throws IOException {}
>   public void preRollBackSplit() throws IOException {}
>   public void postRollBackSplit() throws IOException {}
>   public void postCompleteSplit() throws IOException {}
>
> I am in the process of moving split region a procedure-based from MASTER,
> which means I should move those coprocessors to MasterCoprocessorHost.
>
> Looking at the names, it seems to me that we exposed PONR implementation
> details of split operation (what if we don't have PONR in future
> implementation?  what if a new implementation always PONR from the
> beginning).   I just wondering whether any customer leverage all the
> coprocessors in split?
>
> Also anyone sees any problem moving those CP to Master?  Your insight is
> helpful.
>
> Thanks
> Stephen
>