hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Stepachev (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-13647) Default value for hbase.client.operation.timeout is too high
Date Sat, 30 May 2015 08:08:18 GMT

    [ https://issues.apache.org/jira/browse/HBASE-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14565885#comment-14565885
] 

Andrey Stepachev edited comment on HBASE-13647 at 5/30/15 8:07 AM:
-------------------------------------------------------------------

[~enis] sure, lets fix that.

I'm going to set that to 10 minutes.

Did lookup for all places where this timeout used (for 2.0) and it seems not all places are
good for 10 minutes timeouts (especially in conjunction with number of retries).
|| class || used for || should be ||
| AsyncRpcClient | as netty connection timeout | relates to sockets, so SOCKET_TIMEOUT_CONNECT
is more appropriate |
| HBaseAdmin | used for all calls like createTable | ideally it should be separate and much
larger then 3-5 minutes |
| HRegionServer | used for replica flush call | Integer.MAX not bad for this usecase |
| RegionCoprocessorRpcChannel | used to call coprocessors | separate config option is better,
but regular HBASE_RPC_TIMEOUT_KEY can suite well too |
| RegionReplicaReplicationEndpoint | used to replicate WAL entries | separate config option
is better to allow user to configure how long replication will retry to push WAL edits | 
| HTable (via TableConfiguration) | methods which not use AsyncProcess, as [~enis] mentioned
before | HBASE_RPC_TIMEOUT_KEY is more appropriate as timeout | 

Taking into account this brief scan of usages it seems that we can set not very aggressive
timeout
to 5 or 10 minutes, but need to clean up this in separate jiras.


was (Author: octo47):
[~enis] sure, lets fix that.

did lookup for all places where this timeout used (for 2.0).
|| class || used for || should be ||
| AsyncRpcClient | as netty connection timeout | relates to sockets, so SOCKET_TIMEOUT_CONNECT
is more appropriate |
| HBaseAdmin | used for all calls like createTable | ideally it should be separate and much
larger then 3-5 minutes |
| HRegionServer | used for replica flush call | Integer.MAX not bad for this usecase |
| RegionCoprocessorRpcChannel | used to call coprocessors | separate config option is better,
but regular HBASE_RPC_TIMEOUT_KEY can suite well too |
| RegionReplicaReplicationEndpoint | used to replicate WAL entries | separate config option
is better to allow user to configure how long replication will retry to push WAL edits | 
| HTable (via TableConfiguration) | methods which not use AsyncProcess, as [~enis] mentioned
before | HBASE_RPC_TIMEOUT_KEY is more appropriate as timeout | 

Taking into account this brief scan of usages it seems that we can set not very aggressive
timeout
to 5 or 10 minutes, but need to clean up this in separate jiras.

> 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, 0.98.13, 1.0.2, 1.2.0, 1.1.1
>
>         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)

Mime
View raw message