[
https://issues.apache.org/jira/browse/HBASE-10866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13956067#comment-13956067
]
stack commented on HBASE-10866:
-------------------------------
Writeup looks great. Should have date, author and issue reference attached in
case someone trips over it in wild but this is just a nit. There is actually a
fourth unfortunate use of zk that we'd rather not recall but since you are
making a list, I might as well let you know of it: we persist state into zk for
a few cases; replicating and whether a table is disabled to speak of two (these
we need to undo). The writeup is helpful ([~jxiang] -- you'd be interested).
Regards say RegionServerConsensus, where would such an Interface live in the
code base? Is it only consensus among regionservers? Would the Master need
package access? Thank you.
> 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)
