[ https://issues.apache.org/jira/browse/HBASE-19793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16325682#comment-16325682 ]
stack commented on HBASE-19793: ------------------------------- +1 Good stuff. The read of clusterid from zk rather than just use the clusterid we'd gotten from fs was a recent change of mine. It was a prayer that getting from zk would help w/ flushing out the clusterid since I've seen cases in tests where Master hangs waiting on a read of clusterid w/ ReadOnlyZKClient. Useless, I know but I did it anyway. W/ the recent changes around clusterid -- here and the earlier early setting of clusterid in Master -- hopefully these misreads are a thing of the past. The swap in ordering of connection getting and zk setup makes sense. I'd noticed it earlier but had punted at the time trying to minimize change. +1 > Minor improvements on Master/RS startup > --------------------------------------- > > Key: HBASE-19793 > URL: https://issues.apache.org/jira/browse/HBASE-19793 > Project: HBase > Issue Type: Sub-task > Reporter: Duo Zhang > Assignee: Duo Zhang > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19793.patch > > > Both ZooKeeper and hadoop FileSystem can do fencing, that means, if two > processes try to create one file, only one of them can succeed. So I think we > can move the initialization of ClusterId to the very beginning instead of > only allow active master to do it. > This may helps us solve the complicated dependency issue. -- This message was sent by Atlassian JIRA (v6.4.14#64029)