Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 3750E200C54 for ; Wed, 12 Apr 2017 09:36:47 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 35BA7160B95; Wed, 12 Apr 2017 07:36:47 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 7E008160B8A for ; Wed, 12 Apr 2017 09:36:46 +0200 (CEST) Received: (qmail 85060 invoked by uid 500); 12 Apr 2017 07:36:45 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 85049 invoked by uid 99); 12 Apr 2017 07:36:45 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Apr 2017 07:36:45 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 1596B1AFB53 for ; Wed, 12 Apr 2017 07:36:45 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -100.002 X-Spam-Level: X-Spam-Status: No, score=-100.002 tagged_above=-999 required=6.31 tests=[RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id Jm5WNiiEFAUH for ; Wed, 12 Apr 2017 07:36:44 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 609555FB3D for ; Wed, 12 Apr 2017 07:36:43 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 864BEE06C5 for ; Wed, 12 Apr 2017 07:36:42 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id D07B324066 for ; Wed, 12 Apr 2017 07:36:41 +0000 (UTC) Date: Wed, 12 Apr 2017 07:36:41 +0000 (UTC) From: "Phil Yang (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-17449) Add explicit document on different timeout settings MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Wed, 12 Apr 2017 07:36:47 -0000 [ https://issues.apache.org/jira/browse/HBASE-17449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965507#comment-15965507 ] Phil Yang commented on HBASE-17449: ----------------------------------- [~carp84]Thanks for reminding. I think we have a consensus that hbase.client.scanner.timeout.period should not be used at both client and server side because they have different meaning? The config for scanner rpc timeout should better be have a "rpc" substring, and this config has a substring called "client" so it is very confusing to only use at server... My suggestion is we can first deprecated hbase.client.scanner.timeout.period and introduce two new configs called hbase.rpc.scan.timeout and hbase.regionserver.scanner.ttl. What do you think? And we should consider what is suitable timeout setting on batch. Usually a batch contains many operations so it is slower than single Put/Get. I'm not sure if it should follow rpc timeout and operation timeout. Of course we can just use it because we can have different timeout setting in different Table instances, so maybe it is not a problem. But we should make sure current AP and AsyncClient follow the rule. > Add explicit document on different timeout settings > --------------------------------------------------- > > Key: HBASE-17449 > URL: https://issues.apache.org/jira/browse/HBASE-17449 > Project: HBase > Issue Type: Improvement > Components: documentation > Reporter: Yu Li > Priority: Critical > > Currently we have more than one timeout settings, mainly includes: > * hbase.rpc.timeout > * hbase.client.operation.timeout > * hbase.client.scanner.timeout.period > And in latest branch-1 or master branch code, we will have two other properties: > * hbase.rpc.read.timeout > * hbase.rpc.write.timeout > However, in current refguid we don't have explicit instruction on the difference of these timeout settings (there're explanations for each property, but no instruction on when to use which) > In my understanding, for RPC layer timeout, or say each rpc call: > * Scan (openScanner/next): controlled by hbase.client.scanner.timeout.period > * Other operations: > 1. For released versions: controlled by hbase.rpc.timeout > 2. For 1.4+ versions: read operation controlled by hbase.rpc.read.timeout, write operation controlled by hbase.rpc.write.timeout, or hbase.rpc.timeout if the previous two are not set. > And hbase.client.operation.timeout is a higher-level control counting retry in, or say the overall control for one user call. > After this JIRA, I hope when users ask questions like "What settings I should use if I don't want to wait for more than 1 second for a single put/get/scan.next call", we could give a neat answer. -- This message was sent by Atlassian JIRA (v6.3.15#6346)