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 07CB7200CAF for ; Thu, 18 May 2017 01:59:09 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 065B3160BBA; Wed, 17 May 2017 23:59:09 +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 54259160BCB for ; Thu, 18 May 2017 01:59:08 +0200 (CEST) Received: (qmail 98166 invoked by uid 500); 17 May 2017 23:59:07 -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 98104 invoked by uid 99); 17 May 2017 23:59:07 -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, 17 May 2017 23:59:07 +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 077D0180692 for ; Wed, 17 May 2017 23:59:07 +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-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id eMUl2I0tTMRZ for ; Wed, 17 May 2017 23:59:06 +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 9DEA65FC52 for ; Wed, 17 May 2017 23:59:05 +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 E5064E0D77 for ; Wed, 17 May 2017 23:59:04 +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 2C55D263AB for ; Wed, 17 May 2017 23:59:04 +0000 (UTC) Date: Wed, 17 May 2017 23:59:04 +0000 (UTC) From: "Chinmay Kulkarni (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-17959) Canary timeout should be configurable on a per-table basis MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Wed, 17 May 2017 23:59:09 -0000 [ https://issues.apache.org/jira/browse/HBASE-17959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16014961#comment-16014961 ] Chinmay Kulkarni commented on HBASE-17959: ------------------------------------------ [~apurtell] Thanks for your comments! I have a follow-up question: I chose to use a _HashMap_ instead of a _ConcurrentHashMap_ since we don't really need hashmap bucket-level locking, as we are only concurrently modifying the values corresponding to keys in the hashmap. Using a _ConcurrentHashMap_ could lead to an unnecessarily increased locking granularity since multiple tables (the String keys) could be in the same bucket. Synchronizing access to the whole map itself would lead to even more lock contention. What are your views on this? I will change the logging message for the actual and configured timeouts. Thanks. > Canary timeout should be configurable on a per-table basis > ---------------------------------------------------------- > > Key: HBASE-17959 > URL: https://issues.apache.org/jira/browse/HBASE-17959 > Project: HBase > Issue Type: Improvement > Components: canary > Reporter: Andrew Purtell > Assignee: Chinmay Kulkarni > Priority: Minor > Attachments: HBASE-17959.patch > > > The Canary read and write timeouts should be configurable on a per-table basis, for cases where different tables have different latency SLAs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)