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

Xu Cang commented on HBASE-21991:
---------------------------------

I thought about the race condition you describe above again.  It's a legitimate 
race condition issue. Though, for this line 
"
{code:java}
Meter metric = (Meter) requestsMap.get(requestMeter).get();
{code}
"

Can we just check if "
{code:java}
requestsMap.get(requestMeter)"
{code}
 is not null before we call get() to avoid NPE?
For other operations onto requestsMap, there should be no issues since the map 
itself is concurrentHashMap. The only bug was in the code was after retrieving 
element by using the key, we didn't check null before calling 
{code:java}
get()
{code}
.


> 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
>
>
> 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)

Reply via email to