hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-19793) Minor improvements on Master/RS startup
Date Sun, 14 Jan 2018 17:17:00 GMT

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

Mime
View raw message