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