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

Reply via email to