Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 30 May 2015 08:08:18 +0000 (UTC)
From: "Andrey Stepachev (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12828318.1431081710000.73179.1432973298237@Atlassian.JIRA>
In-Reply-To: <JIRA.12828318.1431081710000@Atlassian.JIRA>
References: <JIRA.12828318.1431081710000@Atlassian.JIRA>
 <JIRA.12828318.1431081710647@arcas>
Subject: [jira] [Comment Edited] (HBASE-13647) Default value for
 hbase.client.operation.timeout is too high
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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