hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17716) Formalize Scan Metric names
Date Thu, 02 Mar 2017 05:44:45 GMT

    [ https://issues.apache.org/jira/browse/HBASE-17716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15891670#comment-15891670

stack commented on HBASE-17716:

Hello [~karanmehta93] Can you say more about why the enum indirection route? What are we guarding
against by doing this?

It is hard for us to change metric naming. These are exported to be consumed by operators.
We can't change the names easily without pissing off folks. Is the thought that we could have
some indirection if we had enum such that phoenix could press on if we changed a metric name?
Would we then have a state where phoenix might refer to a metric with one name but an operator
looking at metrics exported by an hbase cluster would have a different name for a metric (if
we ever changed the metric name)? Should we change all metrics to do this indirection?

Thanks (Metric might be a better enum than MetricType given the metrics you list count different

> 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

View raw message