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 91E33200CCA for ; Wed, 19 Jul 2017 11:49:07 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 90353168A80; Wed, 19 Jul 2017 09:49:07 +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 D6F8F168A7E for ; Wed, 19 Jul 2017 11:49:06 +0200 (CEST) Received: (qmail 50131 invoked by uid 500); 19 Jul 2017 09:49:06 -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 50120 invoked by uid 99); 19 Jul 2017 09:49:06 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Jul 2017 09:49:05 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 5A5FC180313 for ; Wed, 19 Jul 2017 09:49:05 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id tkLxCV68EC7V for ; Wed, 19 Jul 2017 09:49:04 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 67B8C5FD26 for ; Wed, 19 Jul 2017 09:49:02 +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 7CA13E0E36 for ; Wed, 19 Jul 2017 09:49:01 +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 6790021EAE for ; Wed, 19 Jul 2017 09:49:00 +0000 (UTC) Date: Wed, 19 Jul 2017 09:49:00 +0000 (UTC) From: "Chia-Ping Tsai (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-18390) Sleep too long when finding region location failed MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Wed, 19 Jul 2017 09:49:07 -0000 [ https://issues.apache.org/jira/browse/HBASE-18390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16092875#comment-16092875 ] Chia-Ping Tsai commented on HBASE-18390: ---------------------------------------- bq. I reset to the previous commit af359d03b5e2cc798cee8ba52d2a9fcbb1022104 it is also failed. So it is not broken by this issue. Got it. Thanks for the explanations. Will close this. > Sleep too long when finding region location failed > -------------------------------------------------- > > Key: HBASE-18390 > URL: https://issues.apache.org/jira/browse/HBASE-18390 > Project: HBase > Issue Type: Bug > Affects Versions: 1.3.1, 1.2.6, 1.1.11, 2.0.0-alpha-1 > Reporter: Phil Yang > Assignee: Phil Yang > Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-alpha-2, 1.1.12 > > Attachments: HBASE-18390.v01.patch, HBASE-18390.v02.patch, HBASE-18390.v03.patch > > > If RegionServerCallable#prepare failed when getRegionLocation, the location in this callable object is null. And before we retry we will sleep. However, when location is null we will sleep at least 10 seconds. And the request will be failed directly if operation timeout is less than 10 seconds. I think it is no need to keep MIN_WAIT_DEAD_SERVER logic. Use backoff sleeping logic is ok for most cases. -- This message was sent by Atlassian JIRA (v6.4.14#64029)