[
https://issues.apache.org/jira/browse/HBASE-21744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16749309#comment-16749309
]
Sergey Shelukhin commented on HBASE-21744:
------------------------------------------
If the refresh is requested immediately (e.g. due to rapid changes in ZK) then
it should be done immediately, and if it's not requested the wait() call will
wait for the max timeout, so it shouldn't be necessary to sleep. Current code
will queue refresh calls on every change with no delay, too.
Nanosec is used because it's the only reliable way to measure intervals,
currentMillis is affected by ntpd and such and can produce artifacts, including
unchecked exceptions from sleep/wait/etc. because time went backwards. Actually
I should file a bug to fix it in other places, I can see many places in the
code where currentMillis is used for intervals. Hopefully nothing critical is
affected by this.
I'll look to see if a test can be added.
> timeout for server list refresh calls
> --------------------------------------
>
> Key: HBASE-21744
> URL: https://issues.apache.org/jira/browse/HBASE-21744
> Project: HBase
> Issue Type: Bug
> Affects Versions: 3.0.0
> Reporter: Sergey Shelukhin
> Assignee: Sergey Shelukhin
> Priority: Major
> Attachments: HBASE-21744.patch
>
>
> Not sure why yet, but we are seeing the case when cluster is in overall a bad
> state, where after RS dies and deletes its znode, the notification looks like
> it's lost, so the master doesn't detect the failure. ZK itself appears to be
> healthy and doesn't report anything special.
> After some other change is made to the server list, master rescans the list
> and picks up the stale change. Might make sense to add a config that would
> trigger the refresh if it hasn't happened for a while (e.g. 1 minute).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
