[
https://issues.apache.org/jira/browse/HBASE-10866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13956143#comment-13956143
]
Lars Hofhansl commented on HBASE-10866:
---------------------------------------
Hi [~mantonov],
* Nice writeup and separation of the uses of ZK.
* I agree we can treat permanent and transient shared state same. In both cases
it is state shared between servers. When the abstraction is done we can even
have an implementation that stores that state in an HBase table.
* Let's do this piecemeal (as you suggest). But note that if we do not finish
this everywhere we're worse off than before - more classes that do the same
thing and have to modified together.
* o.a.h.h.regionserver.consensus and o.a.h.h.master.consensus seem fine to me.
> 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)