Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 31 Oct 2017 15:17:00 +0000 (UTC)
From: "Appy (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.13112732.1509147949000.112059.1509463020276@Atlassian.JIRA>
In-Reply-To: <JIRA.13112732.1509147949000@Atlassian.JIRA>
References: <JIRA.13112732.1509147949000@Atlassian.JIRA> <JIRA.13112732.1509147949964@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HBASE-19114) Split out o.a.h.h.zookeeper from
 hbase-server and hbase-client
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 31 Oct 2017 15:17:04 -0000


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

Appy commented on HBASE-19114:
------------------------------

bq. ... most zk related code will be in hbase-server...
That's what we are trying to move away from- everything in hbase-server. It has 60% of our codebase - and that too in a very tangled and bad state.

Since packages don't impose circular dependency violations, everything within a single module can depend on everything else. And that has lead this nasty situation. (https://docs.google.com/document/d/1wZAimGcJzc0jys0-EATRi0CyGMVlcIxTvZtegPF4mfw/edit) Those dashed edges are backward dependency and so many of them is a clear signal that we need to design and place our code more appropriately, like in recent times with separate hbase-backup module, hbase-replication module.

bq. We already have too many modules...
I don't know if 10 is too many, or 20, or 30. 100 definitely seems too many. 2 seems too low. Is there a metrics on which we can judge that?  Because am gunning towards straightening our dependencies graph further by splitting out hbase-io and hbase-wal. Advantages are mentioned in that doc mentioned above.

I guess the high level thing here is, anything thats directly zookeeper dependent and doesn't require our internals can be easily split out and kept separately from our internals.


> Split out o.a.h.h.zookeeper from hbase-server and hbase-client
> --------------------------------------------------------------
>
>                 Key: HBASE-19114
>                 URL: https://issues.apache.org/jira/browse/HBASE-19114
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Appy
>            Assignee: Appy
>         Attachments: HBASE-19114.master.001.patch, HBASE-19114.master.002.patch, HBASE-19114.master.003.patch
>
>
> Changes so far:
> - Moved DrainingServerTracker and RegionServerTracker to hbase-server:o.a.h.h.master.
> - Move Abortable to hbase-common. Since it's IA.Private and independent of anything, moving it to hbase-common which is at bottom of the dependency tree is better.
> - Moved RecoveringRegionWatcher to hbase-server:o.a.h.h.regionserver
> - Moved SplitOrMergeTracker to oahh.master (because it depends on a PB)
> - Moving hbase-client:oahh.zookeeper.*  to hbase-zookeeper module. We want to keep hbase-zookeeper very independent and hence at lowest levels in our dependency tree.
> - ZKUtil is a huge tangle since it's linked to almost everything in \[hbase-client/]oahh.zookeeper. And pulling it down requires some basic proto functions (mergeFrom, PBmagic, etc). So what i did was:
>    ** Pulled down common and basic protobuf functions (which only depend on com.google.protobuf.\*) to hbase-common so other code depending on them can be pulled down if possible/wanted in future. This will help future dependency untangling too. These are ProtobufMagic and ProtobufHelpers.
>   ** Didn't move any hbase-specific PB stuff to hbase-common. We can't pull things into hbase-common which add dependency between it and hbase-protobuf/hbase-shaded-protobuf since we very recently untangled them.
> - DEFAULT_REPLICA_ID is used in many places in ZK. Declared a new constant in HConstants (since it's in hbase-common) and using it in hbase-zookeeper. RegionInfo.DEFAULT_REPLICA_ID also takes its value from it to avoid case where two values can become different.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)