[ 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)