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 6CF7B200C2B for ; Thu, 2 Mar 2017 20:14:50 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 6B69A160B7D; Thu, 2 Mar 2017 19:14:50 +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 BFDB4160B6A for ; Thu, 2 Mar 2017 20:14:49 +0100 (CET) Received: (qmail 34785 invoked by uid 500); 2 Mar 2017 19:14:48 -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 34773 invoked by uid 99); 2 Mar 2017 19:14:48 -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; Thu, 02 Mar 2017 19:14:48 +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 83D3E188A04 for ; Thu, 2 Mar 2017 19:14:48 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=6.31 tests=[RP_MATCHES_RCVD=-2.999, SPF_NEUTRAL=0.652] 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 ehI7aaaGHqXR for ; Thu, 2 Mar 2017 19:14:47 +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 7D9F95FC00 for ; Thu, 2 Mar 2017 19:14:47 +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 71703E0A30 for ; Thu, 2 Mar 2017 19:14:46 +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 A72142416E for ; Thu, 2 Mar 2017 19:14:45 +0000 (UTC) Date: Thu, 2 Mar 2017 19:14:45 +0000 (UTC) From: "Samarth Jain (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-17716) Formalize Scan Metric names MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Thu, 02 Mar 2017 19:14:50 -0000 [ https://issues.apache.org/jira/browse/HBASE-17716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15892816#comment-15892816 ] Samarth Jain commented on HBASE-17716: -------------------------------------- [~saint.ack@gmail.com] - the general idea behind this JIRA was to make sure that users of scan metrics like Phoenix can guard against the metric name getting changed behind the scenes. The metric keys aren't exposed today unless someone goes and looks at the HBase source code. Having a metric enum sort of formalizes the contract of the API instead of having plain strings. On a side note, I am not sure of the motivation behind exposing the setCounter() like methods in the ServerSideScanMetrics class. Was it intended to be like a grab-bag where clients can add and update whatever metrics they would like to? If not, then we should really get rid of such methods, and simply initialize the backing map by creating counters for all the enums in the Metric enum. > Formalize Scan Metric names > --------------------------- > > Key: HBASE-17716 > URL: https://issues.apache.org/jira/browse/HBASE-17716 > Project: HBase > Issue Type: Bug > Components: metrics > Reporter: Karan Mehta > Assignee: Karan Mehta > Priority: Minor > Attachments: HBASE-17716.patch > > > HBase provides various metrics through the API's exposed by ScanMetrics class. > The JIRA PHOENIX-3248 requires them to be surfaced through the Phoenix Metrics API. Currently these metrics are referred via hard-coded strings, which are not formal and can break the Phoenix API. Hence we need to refactor the code to assign enums for these metrics. -- This message was sent by Atlassian JIRA (v6.3.15#6346)