[
https://issues.apache.org/jira/browse/HBASE-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14565287#comment-14565287
]
Enis Soztutar commented on HBASE-13647:
---------------------------------------
bq. But we have the same situation with rpc timeout. Should we make an issue to
do something with other timeouts and review them.
RPC timeout is for a single RPC. operation timeout is for the operation with
retrying RPCs. We should not default op timeout to be the operation timeout
since it might mean only a single try, and no retries.
bq. Say, we can add warnings, or fix them (with some common method like
pullUpToZkTimeout)?
Warnings won't cut it. It should be ok to auto set the op timeout by looking at
the zk timeout. If we want (by default) a table operation to ride over RS
crashes is taking into account MTTR: detection + recovery + assignment. Worst
case detection is zk session timeout. For recovery and assignment there is no
easy way to infer that. So the default op timeout should be > zk session
timeout IMO.
> Default value for hbase.client.operation.timeout is too high
> ------------------------------------------------------------
>
> Key: HBASE-13647
> URL: https://issues.apache.org/jira/browse/HBASE-13647
> Project: HBase
> Issue Type: Bug
> Affects Versions: 2.0.0, 1.0.1, 0.98.13, 1.2.0, 1.1.1
> Reporter: Andrey Stepachev
> Assignee: Andrey Stepachev
> Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-13647.patch
>
>
> Default value for hbase.client.operation.timeout is too high, it is LONG.Max.
> That value will block any service calls to coprocessor endpoints indefinitely.
> Should we introduce better default value for that?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
