[
https://issues.apache.org/jira/browse/HBASE-10866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13956135#comment-13956135
]
Mikhail Antonov commented on HBASE-10866:
-----------------------------------------
Regarding essential state being kept in ZK - I guess you're talking about
HBASE-7767 and such? I see following possible approaches (looking from the
position of abstracting ZK usage):
- while doing refactoring, include this permanent shared state as part of
first usecase (transient shared state), as described in writeup. That is
conceptually wrong, but would just be a simple refactoring of ZK usage.
- create another hbase meta table to keep this information. That is probably
right approach, but would be much bigger change?
On the codebase structure - this is how I see it:
- both master and region server will need access to consensus operations. In
example with log splitting, on the master side there's SplitLogManager which is
orchestrating task to replay wal files by creating znodes.
- I'm thinking that at least for now, to make refactoring process more
straightforward and manageable, it may be better to keep consensus parts of
both sides (master and RS) separated in packages like
o.a.h.h.regionserver.consensus (.impl for implementations) and
o.a.h.h.master.consensus (.impl for implementations), and may be after a series
of patches, reconcile common parts into o.a.h.h.consensus. Reasons - consensus
api-related parts on master and regionserver sides can be worked on
independently in many cases, and while the refactoring is in process we can
refactor first region-part, then master-part. Also, in many cases the logic
which needs to be abstracted on region side and master side is specific for
this type of cluster node.
What do you think? May be I'm missing something on the packaging conventions
for HBase though..
> Decouple HLogSplitterHandler from ZooKeeper
> -------------------------------------------
>
> Key: HBASE-10866
> URL: https://issues.apache.org/jira/browse/HBASE-10866
> Project: HBase
> Issue Type: Improvement
> Components: regionserver, Zookeeper
> Reporter: Mikhail Antonov
> Attachments: HBASE-10866.patch, HBASE-10866.patch, HBASE-10866.patch,
> HBASE-10866.patch, HBaseConsensus.pdf
>
>
> As some sort of follow-up or initial step towards HBASE-10296...
> Whatever consensus algorithm/library may be the chosen, perhaps on of first
> practical steps towards this goal would be to better abstract ZK-related API
> and details, which are now throughout the codebase (mostly leaked throuth
> ZkUtil, ZooKeeperWatcher and listeners).
> I'd like to propose a series of patches to help better abstract out zookeeper
> (and then help develop consensus APIs).
> Here is first version of patch for initial review (then I'm planning to work
> on another handlers in regionserver, and then perhaps start working on
> abstracting listeners).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
