hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12260) MasterServices needs a short-back-and-sides; pare-back exposure of internals and IA.Private classes
Date Thu, 12 Oct 2017 22:45:01 GMT

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

stack commented on HBASE-12260:

 * Schedule and wait on flush/compaction
 ** This is RegionServer-side, not Master-side. Can schedule Flush or Compaction via Admin
on Master side but no means for blocking (AsyncAdmin returns a CompletableFuture but it too
is just a request; it does not have the future wait on completion of compaction).
 * Creating system tables (Done via Admin. Testing)
 ** Only Master process can make system tables (while at it, only Master can write hbase:meta).
TODO. Tried but the RpcService is unreliable and we want to check that the request comes from
same process, not just same IP.
 * Review of RSGroups to see what functionality need to add back into MasterServices
 ** This is blocked on RSGroup work. Will require more exposure I think but already the RSGroup
fixup has removed need of our exposing table locks. Thats a big help.
 * Metrics/by-pass
 ** TODO: if bypass is selective and we can update metrics even on bypass, then we won't have
to let out metrics.

So, three follow-ons: only master can make system tables, do we have to expose more functionality
for CPs (see what RSGroup needs when done), and do bypass to see if we need to let out metrics
or not.

> MasterServices needs a short-back-and-sides; pare-back exposure of internals and IA.Private
> ---------------------------------------------------------------------------------------------------
>                 Key: HBASE-12260
>                 URL: https://issues.apache.org/jira/browse/HBASE-12260
>             Project: HBase
>          Issue Type: Sub-task
>          Components: master
>            Reporter: ryan rawson
>            Assignee: stack
>            Priority: Critical
>             Fix For: 2.0.0-alpha-4
>         Attachments: HBASE-12260.master.001.patch, HBASE-12260.master.002.patch, HBASE-12260.master.003.patch,
HBASE-12260.master.004.patch, HBASE-12260.master.005.patch, HBASE-12260.master.006.patch,
HBASE-12260.master.007.patch, HBASE-12260.master.008.patch, HBASE-12260.master.009.patch,
HBASE-12260.master.010.patch, HBASE-12260.master.011.patch, HBASE-12260.master.011.patch,
> A major issue with MasterServices is the MasterCoprocessorEnvironment exposes this class
even though MasterServices is tagged with @InterfaceAudience.Private
> This means that the entire internals of the HMaster is essentially part of the coprocessor
API.  Many of the classes returned by the MasterServices API are highly internal, extremely
powerful, and subject to constant change.  
> Perhaps a new API to replace MasterServices that is use-case focused, and justified based
on real world co-processors would suit things better.

This message was sent by Atlassian JIRA

View raw message