[ https://issues.apache.org/jira/browse/HBASE-21991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16788429#comment-16788429 ]
Xu Cang edited comment on HBASE-21991 at 3/9/19 1:27 AM: --------------------------------------------------------- very good analysis! And the patch looks great. [~jatsakthi] I only have some minor code comments below: For the unit test, {code:java} "try{ connection = UTIL.getConnection();" {code} Please do try-with-resource approach. {code:java} "e.printStackTrace();" {code} Can you log the exception? Also, is that possible to count rows you wrote after all the Put-s done as part of this test? was (Author: xucang): very good analysis! And the patch looks great. [~jatsakthi] I only have some minor code comments below: For the unit test, {code:java} "try{ connection = UTIL.getConnection();" {code} Please do try-with-resource approach. "e.printStackTrace();" Can you log the exception? Also, is that possible to count rows you wrote after all the Put-s done as part of this test? > Fix MetaMetrics issues - [Race condition, Faulty remove logic], few > improvements > -------------------------------------------------------------------------------- > > Key: HBASE-21991 > URL: https://issues.apache.org/jira/browse/HBASE-21991 > Project: HBase > Issue Type: Bug > Components: Coprocessors, metrics > Reporter: Sakthi > Assignee: Sakthi > Priority: Major > Attachments: hbase-21991.master.001.patch, > hbase-21991.master.002.patch > > > Here is a list of the issues related to the MetaMetrics implementation: > +*Bugs*+: > # [_Lossy counting for top-k_] *Faulty remove logic of non-eligible meters*: > Under certain conditions, we might end up storing/exposing all the meters > rather than top-k-ish > # MetaMetrics can throw NPE resulting in aborting of the RS because of a > *Race Condition*. > +*Improvements*+: > # With high number of regions in the cluster, exposure of metrics for each > region blows up the JMX from ~140 Kbs to 100+ Mbs depending on the number of > regions. It's better to use *lossy counting to maintain top-k for region > metrics* as well. > # As the lossy meters do not represent actual counts, I think, it'll be > better to *rename the meters to include "lossy" in the name*. It would be > more informative while monitoring the metrics and there would be less > confusion regarding actual counts to lossy counts. -- This message was sent by Atlassian JIRA (v7.6.3#76005)