[
https://issues.apache.org/jira/browse/HBASE-6411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13421552#comment-13421552
]
Elliott Clark commented on HBASE-6411:
--------------------------------------
bq.Plan to refactor BaseMetricsSource & Impl, if there are no objections
We shouldn't care about dynamic/static metrics registry. They both do the same
things. Right now we have that dichotomy and using it is a giant pain. I
would vote strongly against that. Stack and I discussed long ago how having
both makes it very hard to add dynamic metrics after the fact and how users
should not need to know when somethings are dynamic metrics and others are
static. So it's best to have them together.
bq.. not everyone probably should use JvmMetrics
It's only done once. We do always want to have jvm metrics, and it's better to
have them there than to put that init into the base classes. So far HBase has
put way too much knowledge of metrics into the base
HRegion/HRegionServer/HMaster classes. Putting it in an init of the sources
separates this
{code}
throw new MetricsException("Unsupported incr() for metric "+ name);
{code}
{code}
throw new MetricsException("Unsupported add(value) for metric "+ name);
{code}
Throwing code in metrics code is a big part of the stuff I was trying to avoid.
Since we don't consider metrics exceptions fatal it leads to having to wrap
things in giant try catches. These exceptions are not something that a user
would ever need to know about so we shouldn't throw them.
{code}
+ /**
+ * Increment a metric by name.
+ * @param name of the metric
+ */
+ public void incr(String name) {
+ incr(name, mf);
+ }
{code}
increment shouldn't be on the registry. The registry is there to create and
hold metrics. Others are there to manipulate them. We want the registry to be
functionally close to what's in org.apache.hadoop.metrics2 so that if they ever
add a remove function then we can use that registry wholesale.
Since you've moved the metrics creation out of the source, it's possible that
more then one thread could be using it and everything will need to be done
using concurrent hash maps.
> Move Master Metrics to metrics 2
> --------------------------------
>
> Key: HBASE-6411
> URL: https://issues.apache.org/jira/browse/HBASE-6411
> Project: HBase
> Issue Type: Sub-task
> Reporter: Elliott Clark
> Assignee: Elliott Clark
> Attachments: HBASE-6411-0.patch, HBASE-6411-1.patch,
> HBASE-6411-2.patch, HBASE-6411_concept.patch
>
>
> Move Master Metrics to metrics 2
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
