[
https://issues.apache.org/jira/browse/HBASE-8321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628359#comment-13628359
]
Jeffrey Zhong commented on HBASE-8321:
--------------------------------------
The recoverLease/getReader underlying are single hdfs function calls. It's hard
to heart beat inside them. Last week I talked about this with hdfs folks. It
seems that recoverLease is NN operation so it take about 1 mins in most bad
situations(rpc/socket time out) and getReader is about same if we directly go
to a bad data node(still the rpc/socket timeout value). Two mins in most case
should be good enough.
In addition, hdfs has 30(default) secs timeout to mark a bad data node stale,
therefore other workers(preempted the timeout task) has a good chance to spend
much shorter time to proceed.
IMHO, since we have hbase-6738, we can change the default value even longer
like 15 mins(I set it to 5mins in 0.94) to cover normal cases. For extreme
situations, people can adjust the config setting accordingly.
> Log split worker should heartbeat to avoid timeout
> --------------------------------------------------
>
> Key: HBASE-8321
> URL: https://issues.apache.org/jira/browse/HBASE-8321
> Project: HBase
> Issue Type: Bug
> Components: wal
> Reporter: Jimmy Xiang
> Assignee: Jimmy Xiang
>
> Currently, hlog splitter could spend quite sometime to split a log in case
> any HDFS issue and recoverLease/retry opening is needed. If distributed log
> split manager times out the log worker, other log worker to take over will
> run into the same issue.
> Ideally, we should not need a timeout monitor. Since we have a timeout
> monitor for DSL now, the worker should heartbeat to avoid wrong/unneeded
> timeouts.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
